[Nut-upsdev] RFC: nut and systemd

[Michal Hlavinka]

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

nope. AFAIK packaging is already standardized on all distributions, so only 
new changes needs to be standardized and that is exactly why I sent
this email instead of just doing it Fedora way in Fedora.

> > > >  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

well in distro A all services are configured the same way, so I think it's 
quite easy to configure nut when that task is similar to configuring smartd,
httpd,... I don't think systemd & nut is going to scare users when they 
already understand systemd thanks experience with httpd,dovecot,
smartd,....  So I think it's questionable whether to do everything the same 
way for one package on all systems OR handle package the same way as all 
other packages on system XYZ. If I have experience with Fedora/Debian/
OpenSUSE/Mandriva/... and I want to find out how to set up nut on my system, 
I'd appreciate more when it's done the same way as all other sw on my system
then when it's done the same way on all systems. So I think standardization 
is good (where I can find config file X, documentation,....), but I find init 
system little bit different. I don't think nut&systemd configuration must 
be the same as nut&SysV or nut&upstart, it just seems that systemd is 
going to be adopted by other distributions (definitely not by all of them),
so I'd like to standardize nut&systemd the way which does not need to be 
100 % compatible with SysV init system (at least from my POV).

> - simplicity: you set one "var", instead of 2 in you system.

afaik for upsdrvctl, upsd and upsmon the first two should work together 
always and the third one is independent. So there are two "groups" 
A=upsdrvctl&upsd  and B=upsmon

change from: 
chkconfig ups on
to 
systemctl enable ups.service 
or
systemctl enable ups.service; systemctl enable upsmon.service

does not make that big difference and I think this behavior is 
expected (at least in Fedora/RHEL).


> 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!

MODE can give only 4 possibilities (afaik)
A on | on | off | off
B on | off | on | off

A=upsd+upsdrvctl
B=upsmon

and this can be achieved very easily with just two standard configuration 
commands and thanks splitting nut to 2(3) service files they will work just 
out of the box. I can (will) add simple scriptlet in rpm %post so services are 
configured (on/off) initialy when upgrading from sysv version with 
etc/sysconfig/ups to systemd version.

Anyway, when 2 services and MODE in etc/sysconfig/ups kept, what should 
happen, when:
MODE=A+B, A is running, B stopped and user restarts A?
MODE=A, A+B is running, user restarts A?
...
basically should it stop running service? restart only running? start 
missing? Or simply should it ignore systemd's configuration or should it 
ignore MODE= ? Whatever way it would be, it'd require some ugly hacks 
and script wrapper around executables or auto modification of service 
files (what if user changed anything in service file, should we touch 
that file and break his configuration or ignore MODE=?). It seems to me 
doing it the same way as other services on specific system/distribution
to be better way than trying to have systemd compatible with 
sysv/upstart. Anyway, it's not expected that user changes his init systemd 
as simple update process, but only on system upgrade OR it'll require some 
manual changes.

> 
> > 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?

http://fedoraproject.org/wiki/Features/FMCI (Ignore target release=Fedora 15, 
it's not valid.) This project is combined with (extension to) matahari 
( https://fedorahosted.org/matahari/ ). Current status is that they are 
working to finish backend (dbus and cli) which should be completed for Fedora 
16. Work on gui should start after that.