[Buildbot-devel] Buildbot 1.0: The Shimmering Vision

Brian Warner warner at lothar.com
Fri Aug 15 04:04:39 UTC 2008


(I apologize for the brief response and for the top-posting.. I'm on  
vacation this week and am reading email through a cellphone..)

This all sounds great! I really like the of a clear, attainable goal  
for a 1.0 release.

I'd be happy with a 1.0 that just had the DB-backed status storage and  
"stateless" job scheduler, since they will enable so much more. I'll  
back away from some of the other, more grandiose milestones I used to  
have in mind ("Problem" tracking, IM status delivery, test-case  
parsing, and some others listed on the Trac "roadmap" page).

Both of those projects, as well as any other features that we want to  
put into this release, are going to require a non-zero amount of work,  
and my day job is keeping me too busy to let me write a lot of  
Buildbot code these days. But I can give direction and offer support.  
I have some specific ideas about how to proceed on both the status-db  
and the job-management.. if we can put together a "status-db strike  
force" then I think the coding shouldn't actually be too hard.

Status-db: as we discussed at the user's group meeting as well as on  
the mailing list, the basic question is sqlite (probably in the form  
of Axiom or some other OOPish front-end) or a proper remote SQL scheme  
via twisted.enterprise . The latter probably involves more manual work  
(and more thought about upgrades, etc) but also represents less work  
to switch to other backends in the future and to achieve better  
scaling for large systems. Log files will obviously be kept outside  
the DB, but that makes remote databases trickier to manage. My  
immediate inclination is to go with a local sqlite approach, with  
logfiles sitting next to the db file, but the criticism that this will  
not scale is a valid one.

My expectation is that we can leave the existing IStatus interfaces  
alone and just change the internal implementation. (that's the whole  
reason for IStatus anyways). We'd need to decide if we want to change  
the method definitions to return Deferreds (instead of their current  
synchronous form), though.. sync is fine for sqlite, but not for  
postgres.

For job control, I'm thinking of a separate local database that  
remembers which builds are currently running. The Schedulers would be  
changed to keep their state in this jobdb/buildsdb, and would re- 
examine it at boot time (so restarting the buildmaster won't forget  
about the pending build). The jobdb will track running builds, so a  
restart won't interrupt builds either. The buildslaves already queue  
their command status messages and don't retire them until the master  
acks them.. we just need to enhance this to re-send messages on  
reconnect instead of killing the current command.

In short, I think both of these goals are feasible 1.0 material, and  
if we can organize some people with SQL experience to write the code,  
we should be able to get this stuff done within a couple months.

Many thanks to Dustin for helping us keep up the 1.0 momentum.. let's  
do it!

cheers,
  -Brian



On Aug 12, 2008, at 2:29 PM, "Dustin J. Mitchell" <dustin at zmanda.com>  
wrote:

> On Tue, Aug 12, 2008 at 2:10 PM, Ben Hearsum <bhearsum at mozilla.com>  
> wrote:
>> Stateless client/server protocol would let us restart the master  
>> without
>> killing slave jobs, right? I totally freaking support that. +++++++
>
> /me counts plusses..
>
> Yes, and it would also probably allow non-python buildslaves.  I'm not
> totally sold on the idea -- Buildbot's existing use of PB is *really*
> solid and effective, and I had hoped to keep it.  I wonder if we could
> do both?  Eep.
>
> Dustin
>
> -- 
> Storage Software Engineer
> http://www.zmanda.com
>
> --- 
> ----------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Buildbot-devel mailing list
> Buildbot-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/buildbot-devel




More information about the devel mailing list