[arch-general] Arch Linux support in puppet

[Thomas S Hatch]

On Mon, Mar 14, 2011 at 11:37 AM, Dieter Plaetinck <dieter at plaetinck.be>wrote:

> On Mon, 14 Mar 2011 11:26:08 -0600
> Thomas S Hatch <thatch45 at gmail.com> wrote:
>
> > On Mon, Mar 14, 2011 at 11:09 AM, Dieter Plaetinck
> > <dieter at plaetinck.be>wrote:
> >
> > > On Mon, 14 Mar 2011 10:58:19 -0600
> > > Thomas S Hatch <thatch45 at gmail.com> wrote:
> > >
> > > > But regardless, this should support the Arch style runlevel.
> > >
> > > maybe... in theory it's possible that in a month we switch to
> > > systemd as official init system.  this will probably not happen
> > > (soon), but just saying.
> > >
> > > > I do think that if it is possible to determine the ordering based
> > > > on the requires statements of other services that would be great
> > >
> > > the key thing imho is that currently on a normal, single Arch
> > > install it's the admin who configures the ordering, very explicitly.
> > > Automatically guessing an implicit ordering based on whatever
> > > heuristics is not how Arch currently does it, and probably neither
> > > should puppet.
> > > I don't have any puppet experience, but is it not possible to just
> > > make the admin configure the order in puppet? Or even just define
> > > $DAEMONS in puppet?
> > > It's remarkable that such a simple configuration syntax in rc.conf
> > > (an ordered list of daemons) is causing these issues,
> > > it seems as if puppet tries to abstract (too much?) and now we must
> > > work around the
> > > limitations of that abstraction?
> > >
> > > BTW: I was right across Nigel at the devops dinner in Brussels.
> > > small world :)
> > >
> > > Dieter
> > >
> > >
> > Dieter, the problem is not so much in parsing the DAEMONS array, as
> > it is the fact that in puppet the services are configured from a
> > different logical perspective, rather than configuring what services
> > are to start, you define services individually and then "realize"
> > certain services for certain servers, this makes it hard to
> > implicitly define the daemons array.
> >
> > On the other hand, if require statements could be used to determine
> > the order of the services in the daemons array, then the order would
> > still be explicitly determined by the admin.
> >
> > I mentioned the idea of having an index => param, maybe we could have
> > a before => Service['foo'],
> >
> > or
> >
> > before => foo,
> >
> > to specify that the service should run before the other service.
> >
> > of course the require statement could still fulfill that.
>
> maybe, instead of tens of verbose require/verbose/... statements, how
> about 1 long list of all possible initscripts the admin will ever use
> (or maybe even of all initscripts in Arch, less duplication of efforts),
> and then, this list can be consulted to know the order of the daemons
> which you want in rc.conf
>
> Just throwing the idea out there.
> Dieter
>
I think that maintaining a list like that in Arch would be a good idea, or
at least some sort of dependency document or application, say a small
program that you ask it what other services are required for service x and
it returns those services?
This would also be useful in debugging ordering problems in an admin may
have in the rc.conf.

What do you think?