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

[Juergen Gross <jgross@xxxxxxxx>]

On 27/06/16 14:59, Andrew Cooper wrote:
> 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.

Okay, but this isn't true for the xenstore domain case, resulting in the
need for an explicit dependency then. I don't think doing the same for
xenstored is adding too much time to system startup.

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

I don't know of any way to do this.


Juergen


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