[arch-general] Arch Linux support in puppet

[Thomas S Hatch]

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.