|
|
Boost Interest : |
From: David Abrahams (dave_at_[hidden])
Date: 2008-05-27 14:56:12
on Tue May 27 2008, "troy d. straszheim" <troy-AT-resophonic.com> wrote:
>> 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.
Perhaps; I'm not intimately familiar with the data model.
> 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.
Agreed
>> 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.)
Yes, I was thinking roughly along those lines. A more sophisticated
approach would allow some of what the client sends to be injected into
the platform ID.
> 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.
Yes.
>> 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.
Maybe; I'm not sure what there is to that logic. I'm guessing it has to
be pretty simple, though, yeah?
>>> 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.
"No, there isn't," or "no, I'm not saying that?"
> 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.
Yeah, well we might need to be prepared to maintain some bits and
pieces, but it's important that the bulk of what's used lives elsewhere.
>>> 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.
Cool.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com