Re: Re: try-ark problem: reveal arkbase

Will,

Thanks for the response.

> Now...  If you're starting from NO ARK WHATSOEVER, the first
> thing you gotta do is get the right Python, PyXML, GCC,
> etc., on at least one box of each flavor.
> 
> Second, you've got to kickstart the ARK stuff (again, on at
> least one host of each kind), which (regrettably) means a
> fairly delicate order for getting things started.
> 
> ark-world (now available in
> sidai/ark-pkg-mgmt/ark-world.sample) simply does that second
> bit.  Its last line is simply a fancy 'ark package reveal
> ALL'; in fact, most of its huff-and-puff is to support a
> --scrub option, **WHICH YOU USE AT GREAT PERIL**.
> 
> try-ark (sample1/try-ark/try-ark) is simply an ark-world
> with some sanity-checking of your XML files stuck on the
> front.  (Simply because: if you run ARK with duff XML files,
> e.g. referring to hosts that don't exist at your site, you
> will get utterly incomprehensible Python-traceback
> messages.)

Yes, and I believe that it would be Good to find a way to make this
bootstrap process Much Easier.

I'll be working on this over the next few days.

And yes, when I was discussing development, testing, and production teams I
chose sidai, a policy team, as an example, instead of glasli1, a "site" team
(or whatever).

Regardless, I gather we all agree that it is a Good Thing to be able to
mix/match production/testing/development teams.

Next, I was thinking that (assuming it doesn't work this way already) while
a policy team (sidai) is a logical place to put all of the packages that
*MIGHT* be built/deployed/revealed, I think the policy team should only hold
the *specs* on things and not do any "work".  All of the compiling,
revealing, and deploying should be done by glasli1-style teams.

For example, as a policy matter I might decide what versions of all of the
GNU software I want, but if I'm installing software on machines for team Y I
only want a small subset of the entire list of GNU tools to be loaded.

More later - time for sleep.

H