On Mon, Mar 14, 2011 at 12:03 PM, C Anthony Risinger <anthony@extof.me>wrote:
On Mon, Mar 14, 2011 at 11:24 AM, Lee Burton <lburton@mrow.org> wrote:
Append is okay (most likely dependencies are already in place for a service), but it would be nice to specify dependencies / ensure necessary services are running. We should allow the module writer / administrator to specify these dependencies so they can specify custom depends/etc. The logic should allow one to specify logical "or" statements (say wicd vs network manager vs netcfg vs network) and should try to place the puppet configured service after all of its dependencies adding them to the line if possible (OR statements may make this hard... perhaps a default to add if one isn't present?) or producing some sort of error/exception. The point should be to give the admin full control of what happens to his / her rc.conf ;) -Lee
I agree, the admin should have the ability to manage the service loading sequence. I think that this could be done with require statements, simply saying
On Mon, Mar 14, 2011 at 12:29 PM, Thomas S Hatch <thatch45@gmail.com> wrote: that
if a service requires another service then it is placed at an earlier index in the DAEMON array.
yeah but then you have the (common) condition where services are not connected to the same hierarchy of dependencies, but you sinply want one after/before the other for whatever reason. systemd handles this with Require/Conflicts, AND Before/After keywords (as you earlier mentioned) ... because they are orthogonal. Require/Conflicts is traditional deps, Before/After is essentially "should these two services happen to be started at the same time, do X before Y". it doesn't matter if puppet actually starts them one at a time; the order is ambiguous. in short, you'd need both unless you want things to get fuzzy w/Requires only ...
... but at that point your replicating the existing, _working_, functionality of systemd; a problem that is being solved by a much larger group at a widespread level (eg. upstream), with the intention of eradicating all this nonsense amongst distros. i'm not trying to beat the drums here, just saying that it's nothing like upstart, and IMO ... is a welcomed addition ... as a _long_ overdue face lift to the crusty/error-prone black-box bash gigantamatron we call "the init process" (and while it does work well enough, we _do_ want to move forward, yes?).
anyways ... i'm really trying not to go on a tangent here, but you explicitly say:
"you define services individually and then "realize" certain services [on the target server]"
and that's exactly what systemd would do for you -- with no additional work on puppet or arch's end; i'm just trying to suggest the best tool for the job, that's all, even if it's not (yet/ever) officially endorsed by the arch high commanders ... i'm a lazy [pragmatic] developer/sysadmin ... and the init process simply is destine for change.
... yes, yes -- i'll just stand aside and listen from this point on :-)
C Anthony
I think that the unfolding systemd issues here and the fact that we may be required to move to systemd might rewrite this problem altogether, in which case systemd would translate ordering and the order of services as they are placed in the daemons array may be irrelevant. I will do some more research.