[arch-general] Arch Linux support in puppet

C Anthony Risinger anthony at extof.me
Mon Mar 14 14:03:36 EDT 2011


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


More information about the arch-general mailing list