[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] making xenstore domain easy configurable



On 27/06/16 13:43, Juergen Gross wrote:
> I'm just writing some patches to make it easy to switch between
> xenstore daemon and xenstore domain. My plan is to achieve this
> by a global configuration file containing configuration options
> for the host (e.g. /etc/xen/xen.conf).
>
> With the current systemd support this is not easy. There are
> systemd socket definitions to let systemd create the sockets for
> xenstored. As the sockets are not to be created in case xenstore
> is running in a xenstore domain things are becoming complicated.
>
> Today we have the following xenstore related systemd items:
>
> - xenstored_ro.socket and xenstored.socket
> - xenstored.service depending on the sockets
> - other services depending on xenstored.service
>
> A xenstore domain would need:
>
> - xenstore-domain.service
> - other services depending on xenstore-domain.service
>
> Being able to switch between both schemes just via a config file
> seems to be not easy, at least I don't know of any way to do the
> socket creation only in case they are required without breaking
> the dependency chain.
>
> So I'd suggest to remove xenstored_ro.socket and xenstored.socket
> and let xenstored create the sockets (as it is doing without
> systemd). I'm not aware of any disadvantage, as xenstored isn't
> restartable and thus can't take advantage of the permanent sockets
> offered by systemd.
>
> This would mean I could rip out the systemd specific stuff from
> xenstored and oxenstored. I could create a single xenstore.service
> script evaluating the config file and starting the correct xenstore
> (xenstored or xenstore domain). The other services would then depend
> on xenstore.service. This would remove the need to specify the
> type of xenstore daemon/domain (ocaml based or C based) in the systemd
> file, too.
>
> Is there a better way to achieve what I want? Any other opinions?

This isn't the only advantage offered by socket activation.

As currently configured, every service which depends on xenstored.socket
can be started in parallel (as systemd creates the sockets ahead of
time), with the dependent services blocking a little on the socket while
xenstored starts up sufficiently to service the requests.

In the case that xenstored is running in the local domain, socket
activation is a useful function to have.

OTOH, having anything explicitly depend on xenstored.socket is broken in
a model where xenstored might be running in a separate domain.  I don't
suppose systemd has any way of specifying "conditionally might have a
socket"?

~Andrew

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.