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

[Don Koch <dkoch@xxxxxxxxxxx>]

On Wed, 28 May 2014 10:30:49 +0100
Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:

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

How about moving xencommons into /etc/xen and, optionally, making a
link to it from /etc/{default,sysconfig} as the distro warrants? That
way we have a consistent place to find it and the user still finds it
where they're used to finding it.

-d

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel