[Nut-upsdev] RFC: nut and systemd
mhlavink at redhat.com
Tue Apr 26 09:23:36 UTC 2011
> you've completely missed my invitation to talk about packaging
> 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
chkconfig ups on
systemctl enable ups.service
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
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
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
> > 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.
More information about the Nut-upsdev