On Mon, Mar 14, 2011 at 11:37 AM, Dieter Plaetinck <dieter@xxxxxxxxxxxx>wrote: > On Mon, 14 Mar 2011 11:26:08 -0600 > Thomas S Hatch <thatch45@xxxxxxxxx> wrote: > > > On Mon, Mar 14, 2011 at 11:09 AM, Dieter Plaetinck > > <dieter@xxxxxxxxxxxx>wrote: > > > > > On Mon, 14 Mar 2011 10:58:19 -0600 > > > Thomas S Hatch <thatch45@xxxxxxxxx> 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?
