Re: [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference

[Ian Campbell <Ian.Campbell@citrix.com>]

On Sat, 2014-05-24 at 01:20 +0200, Luis R. Rodriguez wrote:
> On Thu, May 22, 2014 at 11:05:47AM +0100, Ian Campbell wrote:
> > On Thu, 2014-05-22 at 01:02 +0200, Luis R. Rodriguez wrote:
> > > > It might be reasonable for hotplugpath.sh to define
> > > > XENSTORE_xenstored=/path/to/xenstored
> > > > XENSTORE_oxenstored=/path/to/oxenstored
> > > > 
> > > > and use the existing XENSTORED variable in sysconfig to select which.
> > > 
> > > Ah but but hotplugpath.sh is one of those automatically generated files
> > > and after my last patch in this series they are all now shared in one
> > > master file, config/xen-environment-scripts.in, and since the we want
> > > to keep script file Shell / Python agnostic checking which one is set
> > > on sysconfig is not something reasonable to do on that master file.
> > 
> > Well, it must be possible to change which xenstored implementation is
> > used by editing a single setting in /etc/{sysconfig,default}/xencommons,
> > maybe that means more code somewhere, I don't know. idieally you would
> > be able to say
> > XENSTORE=xenstored # C xenstore at default path
> > XENSTORE=oxenstored # Ocaml xenstore at default path
> > XENSTORE=/path/to/something # xenstored at some custom path.
> 
> Agreed.
> 
> > > My series of patches already deals with the old init and xencommons script to
> > > start xenstore, it used the hotplugpath.sh for deducing the xenstore
> > > daemon it should use by default and switching this to rely on the sysconfig
> > > xencommons should be easy if it wasn't already dealt with there already.
> > > 
> > > For systemd though we can't use varibles on ExecStart for the process, we
> > > however can use environment variables. We have a few options. Fedora's
> > > approach was to use two service unit files which conflicted with each other,
> > > although I'm sure we can work it out by using a target unit and let folks
> > > flip it seems rather silly to me to maintain two service unit files with
> > > identical entries. Therefore in my new approach usres would have to manually
> > > edit the service file with the differnt path / binary. Another possibility
> > > is to have a central launcher binary that just does getenv() and execve()
> > > on the desired binary. If this is agreeable I can work on it and it could
> > > even be shared by the old init as well.
> > 
> > Which is considered the most "systemd" approach?
> 
> Systemd tries to even recommend to shy away from sysconfig/default directory for
> stashing entries, one can set environment variables within the service unit itself,
> but if we are to maintain compatiblity with old stuff relying on sysconfig seems
> the reasonable and accepted way, then we'd include that file as part of the
> running environment, just as our systemd service unit files do now in this series.

I'm mostly concerned that people *not* using systemd can continue to
use /etc/{default,sysconfig}/xencommons in the way which they are used
to.

For people who are using systemd the question is whether it is more or
less confusing to have an unused /etc/{default,sysconfig}/xencommons
sitting there vs. doing things in the less "systemd" way. The compromise
is perhaps to seed the defaults from /e/{d,s}/xencommons but allow them
to be changed in either that file or in the unit file? Is that possible?

> 
> More details here:
> 
> http://0pointer.de/blog/projects/on-etc-sysinit.html
> 
> As for dynamic use daemons, there aren't good examples but the undocumented way
> of doing this but as a per a conversation at the LF Linux Collaboration summit
> one way to deal with this is to use one service target files for defining what
> we do, we'd have two separate service unit files for each cxenstored and
> oxenstored, the services that need to depend on it would depend on the target,
> not the actual service unit files, the user then would have to enable one or
> the other. A sysconfig edit however would not trigger a change, which is what
> we seem to want,

What do you mean? I don't expect editing sysconfig will automagically do
anything, some further action would be required, and since xenstored is
involved that further action most likely involves a reboot.

Can a systemd unit "soft fail"? i.e. fail but not make a huge red
highlighted fuss about it? Then each of the two units could check if
they were configured and softfail if not (expecting that the other one
is configured). Alternatively perhaps there is some sort of pre-check
hook which could be used to see if the unit can/should be run?

Ian.