Re: [PATCH 1/2] tools: remove systemd xenstore socket definitions

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 20/07/16 13:08, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [Xen-devel] [PATCH 1/2] tools: remove systemd xenstore socket definitions"):
>> On 20/07/16 12:12, Juergen Gross wrote:
>>> To be clear: I don't want to avoid systemd by any means. I just don't
>>> want to have a complex and ugly solution with no gain just because
>>> doing it the systemd way.
>> Given the introduction of this new choice, I agree that socket
>> activation isn't sensible.  In the grand scheme of things it doesn't buy
>> you much, as xenstored does not match the intended use for socket
>> activation (on-demand launch of services when something tries to use its
>> socket), as it is a start of day service that runs forever.
> xenstore in its own domain is not a `new choice' which is being
> `introduced'.  It has been supported by Xen upstream for a long time.
> AFAICT from what Juergen is saying it seems that it was broken on
> systemd systems by systemd-specific configuration.

I know that the concept of a xenstored stubdomain isn't new, but
sensible configuration and integration into the $INITSYSTEM_OF_CHOICE
definitely is new.

For the record, I fully support the general direction being taken.
Juergen is doing a stellar job improving the status quo, and this will
be great for the Xen community moving forwards.


However, calling what previously exists WRT xenstored stubdomains as
"supported" is laughable.  The lack of integration meant that anyone
trying to use it had to make intrusive modifications to make it start
properly, and the lack of MiniOS ballooning shows that inadequate
consideration was given to production usecases.  It is disingenuous
pretend that stub-xenstored is anywhere beyond "demo" in terms of
real-world usage at the moment.

~Andrew

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