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

["Luis R. Rodriguez" <mcgrof@xxxxxxxx>]

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.

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, and the only reasonable and *clean* way I can think of
supporting this on systemd is through a launcher which does getenv() and
execve(). If we do that we could rename The C version of xenstored to cxenstored
leave oxenstored as is and have the launcher eat up the xenstored name.

I've poked systemd-devel for more advice:

http://lists.freedesktop.org/archives/systemd-devel/2014-May/019427.html

Unfortunatley no one has provided further input than what I got at LF 
collaboration
summit. One thought that occurs to me is to have systemd deal with these types 
of
situations a launcher of its own, but that's work and perhaps something to 
consider
for the future. The one thing that concerns me about the sysconfig/default 
variable
reliance is that its not ideally what we what but hey -- I don't think we can 
seek
for perfection right now, only a good start.

A launcher is my own preferred way to deal with this, provided I haven't gotten
more input let me know all your folks thought on this. I'll also poke internally
at SUSE for more thoughts.

> > > >  XEN_PAGING_DIR=/var/lib/xen/xenpaging
> > > >  AC_SUBST(XEN_PAGING_DIR)
> > > > +
> > > > +AC_DEFUN([AX_XEN_OCAML_XENSTORE_CHECK], [
> > > > +       AC_PROG_OCAML
> > > > +       AC_PROG_FINDLIB
> > > > +       AS_IF([test "x$OCAMLC" = "xno" || test "x$OCAMLFIND" = "xno"], [
> > > 
> > > THen you could rely on m4/ocaml.m4 to have checked all this already.
> > 
> > Just including m4/ocaml.m4 won't get us much, the above logic assumes
> > that file was included so there is a bit of a trick we need to adjust
> > in order to avoid multiple calls to the same checks.
> 
> If you do/call these checks in tools/configure.ac then I think you can
> just arrange to sequence things correctly with the ocaml ones by the
> ordering in the file.

OK.

  Luis

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