On Mon, 14 Mar 2011 11:26:08 -0600 Thomas S Hatch <thatch45@gmail.com> wrote:
On Mon, Mar 14, 2011 at 11:09 AM, Dieter Plaetinck <dieter@plaetinck.be>wrote:
On Mon, 14 Mar 2011 10:58:19 -0600 Thomas S Hatch <thatch45@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