[arch-general] Arch Linux support in puppet

[Thomas S Hatch]

On Mon, Mar 14, 2011 at 12:03 PM, C Anthony Risinger <anthony at extof.me>wrote:

> On Mon, Mar 14, 2011 at 12:29 PM, Thomas S Hatch <thatch45 at gmail.com>
> wrote:
> > On Mon, Mar 14, 2011 at 11:24 AM, Lee Burton <lburton at 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
> 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.