[Nut-upsdev] RFC: nut and systemd

[Arnaud Quette]

Michal,

you've completely missed my invitation to talk about packaging
standardization:
was it intentional?

@Stan: would you have some time to talk about it too?

2011/4/21 Michal Hlavinka

> > >  That way, slower shell scripts
> > >>> only execute once when the system administrator changes the
> > >>> configuration, and systemd would read those generated files.
> > >>>
> > >>
> > >> Still the same question, what do you want/need that script for?
> > >>
> > >
> > > Maybe it's just a convenience that we don't really need. Arnaud?
> > >
> >
> > I can't say it's a convenience, at least not more or less than the files
> it
> > tries to replace.
> > whatever the number of init script / service files, we need to instruct
> the
> > system which NUT components it has to start.
> > And having a way to do it the same across systems is worth IMHO.
> >
> > that being said, the shell approach doesn't satisfy me much, but was a
> good
> > compromise for a first round.
> > part of the work around the configuration, we might consider a config
> > accessor, like:
> > $ nut-config --get-mode
> >
> > @Michal: would that suit systemd way of life?
>
> I probably don't understand what is it supposed to help with?


- standardisation: one way (ie root source of setting, not way to obtain the
setting) for all systems, whatever distro, whatever init
- simplicity: you set one "var", instead of 2 in you system.

just remember that, part of the roadmap, there is a configuration tools
planned. and the above "nut-config" is the CLI side.
having to manage bagazillion of different package names, binaries paths,
user names, init config, (...) has refrained such efforts until now.

many other effort would greatly benefit from an overall standardization of
NUT distribution!

If we use
> shell script "one for all" starting everything needed (based on MODE in
> nut.conf),
> it'd be equal to option 3) from first email. Getting required mode from
> nut-config
> compared to getting it from nut.conf is no better from systemd's POV.
> Option
> "3)" is not prefered compared to option 4), but there's no enforcement
> policy
> about this. So, they won't like us, but we can ignore their grumbling :o)
> btw, systemd supports:
> EnvironmentFile=/some/config/file (containing ABC=foo)
> ExecStart=/sbin/daemon -abc $ABC
>
> but it does not support /some/config/file containing ABC=$(get-config
> --abc)
> nor ExecStart=/sbin/daemon -abc $(get-config --abc)
>

do not confuse splitting services into separate files (we are all ok with
option 4)
and triggering or conditioning service startup.

the former can be linked to package splitting, ie upsmon is part of
nut-client along with its service file.
while drivers/upsd are part of the core.

the latter is related to nut.conf and... well, I still fail to see how
systemd provides this.
you've mentioned /etc/sysconfig/ups removal, but no replacement mechanism!

> a side question: what is the status of Augeas (still RH sponsored project)
> > in Fedora / RedHat?
>
> It's installable on Fedora and it's still actively developed, but I don't
> know about
> anything using it.
>

mcollective seems to be a first step toward something useful.
I'm astonished that RH guys have not started converting system-config-* to
augeas, nor developed infrastructure tools!
or did I miss something?

cheers,
Arno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20110423/95785add/attachment.htm>