[TIP] Nosejobs!

[Doug Philips]

On or about Friday, April 10, 2009, at 02:12PM, Jesse Noller indited:
>Facelift provisions from pre-built images; those images have certain
>resources already online, such as the daemon, python and anything else
>I need and can pre-allocate on the OS. I've done this before with PXE
>booting, and it worked quite well.

Ugh, that is way more heavy weight than something simple. Also PXE booting, while simplistic, is hardly simple either, esp for a vastly distributed set up where you might not have complete control. That is one place that buildbot rocks. Complete control over the slave host is one kind of simplicity. Not needing that kind of control is a more powerful form of simplicity.



>Clients report back (or can be polled) for results encapsulated in
>JSON or YAML (since it's cross language and stupid simple).

What's your opinion on the Pandokia format? Do you need the nesting that JSON provides? If JSON isn't "for free" in the standard python library, I'm not sure that extra dependency is worth it over the Pandokia format's simplicity...



>All communication is secure (SSL) as this is intended to be a highly
>distributed system.

?? I thought in other threads you were saying that SSL was way too fragile? Must be on email memory overload.



>If resources are unavailable, the client-server (nosejobs) reports
>such, and it can be dealt with. If something goes out for tacos, we
>deal with it.

Oh the lies begin... :) "deal with it" hides a world of complexity hurt.
You've got the firewood under the pot holding the frog... (see below for more on the FUD :) )


>Yup - the important thing is to have a constant and clear feedback
>loop - log failures - ANY failures, log errors, log broken clients,

Agreed.

>A problem like this shares many attributes with distributed systems -
>you have to be able to withstand faults, transient issues, homogeny on
>the network and so on.

Quite so. What you are talking about is remote job management.
That the jobs "happen to be tests" is irrelevant.


>> Also, critically, of documentation. One of my huge takeaways from #pycon was not just how much
>> good can come from competitive groups (Jython, IronPython, etc.) but also how much FUD there
>> is because projects don't do enough to explain their work and make it accessible.
>
>I'm interested in the FUD you speak of, but I agree: I can't be
>screwed trying to grok something with abysmal documentation, or
>confusing and sadness inducing code.

Indeed. Look at the scorn that Zope or Plone gets. I was meta-amused, but saddened, by the Zope lightning talk:
'"oooh, couch DB" - we've been there, done that for a long time.'

Because either they don't have a nice learning ramp with training wheels or good docs or whatever.

Attended a Jython Open Space Thursday before #pycon started. They were lamenting that most folks thought Jython was dead because the front page of the web site hadn't been updated in forever... (I believe they've started to fix that now).



>> What I hear you saying is that it is too hard to figure out if some existing tools do what you want,
>>so it is easier to just go off and invent your own.
>
>No, what you hear me saying is "I've tried all of this other stuff,
>and while I might adapt some of it, it doesn't fit my needs, it
>doesn't scale, it's obtuse, broken, or non applicable".

Fair enough, I'm new to this list, and if this is old ground, my apologies.



>...I've built several systems (and multiple iterations of each) like this, and I'm tired of doing it
>again and again; ergo, I am going to do it, open source it, so I don't have to do it again.

:)

>> I'm really looking forward to seeing what pony-build might be, so I hope Titus gets around to spec'ing his version of simple build pony stuff soon. :)

>Meh, Titus' idea is simple enough that a spec might just muddy it up
>;)

Maybe, but if it is too hard to describe, it is too hard to get right.
The product is the spec? Hmmm, CPython vs. Jython vs. IronPython vs. PyPy - need to go that route? Again?
Pandokia's spec seems awful simple.
Personally, I'm rather fond of Titus' initial proposal: Work out the results level protocol, then build tools around that. Yes, you might want to build tools to help work that out, but if you've done lots of these systems before, as have some of the rest of us, we should be able to leverage that knowledge...


>As it is, I threw the nosejobs out there as the starting point of
>something larger I want to do. I don't have all the answers yet - but
>I have a lot of ideas. I'm also not interested in debating semantics
>until doomsday - I'm a fan of development-by-fiat.

Fiat away. I might even pitch in if you don't use CVS or SVN :)
I'll certainly call BS when it see it, if nothing else. :)

-Doug