|
|
Boost Interest : |
From: troy d. straszheim (troy_at_[hidden])
Date: 2008-05-27 11:44:32
David Abrahams wrote:
>> Quick-ish report on this:
>>
>> I spent several days hacking on bitten. There are a few things that
>> Dave and I discussed that need fixing.
>
> I would put it less strongly. Bitten is usable for us today, but there
> are definitely a few things that could be improved.
Looks like I was working on different assumptions. See below.
> Recipes are not a big flexibility problem for us. It's easy to modify
> run.py to selectively skip libraries on a given tester's machine based
> on some configuration file they set up. The guy who only wants to test
> serialization could simply turn off testing of all the other libraries.
> If you want to make the progress display more sensible, only a *small*
> change to Bitten would be required for slaves to report back that they
> will perform 4 out of the full 92 build steps (or whatever). Yes, it's
> not as elegant as it could be, but it would work.
I hadn't looked at your bjam tweaks, I was focused on cmake/ctest
and bitten with toy recipes.
I'd taken from our conversation that all this coupling of recipes
to platforms to 'build configurations' was A Big Problem. Anyhow,
I see what you're doing there. Agreed, it isn't as elegant as
it could be, but it would work.
> An incremental way to
> make it more elegant would be that the slave sends a recipe back to the
> server describing what it intends to do.
I still think that when slaves start sending recipes to bitten, the data model
unravels and the changes are significant. And they're changes that I believe
C. Lenz doesn't particularly want upstream, he likes the model the way it is.
But I'm not going to argue it further without going back and looking
at it. It doesn't seem pressing right now.
> The real flexibility issue lies in the list of target platforms. Mine
> currently looks like this:
>
> Darwin
>
> * os ~= Darwin
>
> Linux 64-bit GCC 4.1.2
>
> * os ~= [lL]inux
> * boost.toolsets ~= gcc-4.1.2
>
> Linux GCC 4.3.0
>
> * os ~= ^[Ll]inux
> * boost.toolsets ~= ^gcc-4.3.0
>
> Solaris x86 SunPro 5.9 32-bit
>
> * boost.toolsets ~= sun-5.9
> * boost.bjam_options ~= ^.*(?!address-model=64)
>
> Windows 64-bit MSVC 8.0
>
> * version ~= ^[Ww]indows
> * boost.toolsets ~= msvc-8.0
>
> Windows MSVC-9.0
>
> * version ~= ^[Ww]indows
> * boost.toolsets ~= msvc-9.0
>
> When a slave asks the server for work to do, it identifies itself via a
> few built-in configuration variables,
>
> os:
> The name of the operating system (for example "Darwin")
> family:
> The type of operating system (for example "posix" or "nt")
> version:
> The operating system version (for example "8.10.1)
> machine:
> The hardware architecture (for example "i386")
> processor:
> The CPU model (for example "i386", this may be empty or the same as for machine)
> name:
> The name of the slave
> ipnr:
> The IP address of the slave
>
> and any other optional variables that the administrators of the system
> want to use in their build recipes (boost.toolsets and
> boost.bjam_options are examples of the latter in my list above).
Perfectly clear...
>
> ** Here is the key thing that needs to change **
>
> The server then matches the slave against the list of target platforms
> to identify which platform it is. If it matches a target platform X
> (e.g. "Windows MSVC-9.0" above), it asks whether there are any SVN
> repo versions containing changes in the recipe's area of the repo that
> haven't been tested on X.*
> If so, it begins sending recipe steps to the slave and will use the
> slave's results as the official results for that target platform. If
> not, the server says "nothing to do."
>
> * (actually, whether it tests every revision in a range or only the
> latest revision is configurable, but it always starts with the most
> recent changes and works its way back in time)
>
> The upshot is that, without changes to the target platform list from
> someone with trac webadmin privileges (e.g. a moderator), a new tester
> coming on-line can only contribute to the pool of testing power for
> existing platforms (and in the same area of the repo). IMO fixing this
> **would also be really easy** if we knew what we wanted. So that's the
> discussion I think we need to have: what happens when a new slave comes
> on line and how is it reported.
If there were a catchall category 'unknown' that was matched last (and always matched),
things would work... but only for one unknown client. With two clients
of unknown OS'es, the server would dole out builds from the same logical queue, and
the clients would not both perform all builds. To address this you could conceivably put in a
kind of trigger: when an unknown platform calls up and asks for a build,
a platform is automatically created that matches whatever the new platform sent,
and only that (i.e. the regexes are all full-string matches... only platforms that send
in identical information will match.)
One downside could be that this page:
https://boost-consulting.com/trac/projects/boost/build
ends up with quite a number of crufty platforms on it. They'd be easy enough
to clean up manually, though, and long-term you could think about doing it automatically.
>> What Dave and I discussed was bitten with less Control and more
>> Display. If clients are to be allowed to formulate their own recipes,
>> the protocol and database need changing (clients need to report the
>> recipe, at some point, along with "Here are the results for step 7 of
>> that recipe that I said I was working on".)
>
> But clients don't need to be able to formulate their own recipes, at
> least not yet.
Foo. Again, that wasn't one of my operating assumptions.
>> I got this much of it
>> done as part of just learning to hack on trac plugins, then noticed
>> that the queueing logic will need modification,
>
> I think the queueing may be somewhat broken ATM, but I'd be interested
> in knowing what changes you see as needed.
I only meant that the queueing logic would need modification if clients provided
recipes.
>> as well as the association between platforms and urls/recipes... it
>> looks like basically a rewrite.
>
> Are you saying there isn't much more to Bitten than that?
No. Only that once you've got clients concocting their own recipes,
the changes to the server are significant enough that it would be a major
pain to get things integrated to the point where C. Lenz would take
them upstream: so major, it is easier to just rewrite it. I'm willing
to be convinced otherwise, and maybe it is a moot point as we're not going
to do anything that we have to maintain.
>> I haven't yet thought about CTest, transforming CTest XML to
>> bitten-palatable format, automatic generation of build/test recipes
>> from cmake, or the possibility of some entirely different test-running
>> mechanism than ctest. For what I have been doing, dummy builds
>> suffice. I'm willing to switch to this though.... We could decide for
>> now to bear with the extra administrative overhead of the current
>> bitten and focus on this stuff instead. Comments?
>
> I'd be more than happy to work on Bitten mods with you.
>
It seems that the minor tweaks above aren't a big problem. There
is still the business of integrating this with ctest, though. I'll
send out my thinking on this later.
-t