Re: New host challenges: configuration files

[Will P. <pa...@dc...>]

Joel S raises a very real concern/issue w/ existing ARK
stuff.  Some Good Ideas would be welcome in this domain.
Let me take things out of order...

> As a workaround, I ran "ark-invasive --hosts=newhost
> package-config" for each config package. ...

Hmmm... sounds familiar :-(  An "ark-invasive
--hosts=newhost sidai:ark-diffing-deploy" is mildly better.

> Arusha manages a large and growing number of system configuration files:
> password, group, automounter, syslog, and many more.

[The usual disclaimer, for casual onlookers: ARK does not
force you do manage these files in this way.]

> The ark packages for many of these files use a two phase
> approach:
> 
> -- First, a master configuration file or template is constructed from data
> on the gold server by <configure> and <compile> methods.

One goal I'd like to hang onto for that stage is that you
can create the config files for a host *before* it is up.

> When a new host is bootstrapped into ark's world, the <configure> and
> <compile> methods are not rerun automatically. ...

Could we get rid of the 'recordable="yes"' settings on the
methods between <configure> and <deploy>?  If you did 'ark
package deploy ...', it would then have to go right back to
configure.

A related problem that you didn't mention is needing to
re-deploy some packages on hosts *other* than the new one.
For example, the NFS servers need to be told to export to
the new host.

A "solution" that might work in *some* contexts is to have a
pre-populated set of "pending" hosts -- e.g. if you have a
lab full of 40 Linux boxes, you could have another 20
pending ones (on the grounds of "if we get some more boxes,
we know how they will be configured").  All the
configuration stuff is supposed to include pending hosts
("they'll appear any moment now") in its output.

As I say, all ideas welcome.  It's hard to know how to make
configuration do the right thing for hosts that you don't
know you're going to have :-)

Will