Re: [Xen-devel] [PATCH] systemd: add support initial systemd service files

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 12/03/14 11:25, Ian Campbell wrote:
> On Wed, 2014-03-12 at 11:14 +0000, Ian Jackson wrote:
>> Jacek Konieczny writes ("Re: [Xen-devel] [PATCH] systemd: add support 
>> initial systemd service files"):
>>> These seems quite wrong to me. Why create systemd services, while they
>>> are only wrappers to the old-style LSB scripts? What do we gain?
>> I agree with this criticism.
>>
>>> The right thing to do is to provide separate systemd unit for xenstored
>>> and xenconsoled.
>> If we do this then things will break if we add new functionality to
>> xencommons.  We would have to ask contributors who added new code to
>> xencommons to update the systemd unit files.  Those contributors, and
>> we, might not be able to test them (or alternatively wouldn't test the
>> sysvinit scripts).
> I hadn't thought of this aspect, it is a concern.
>
> On the other hand if systemd using distros are carrying their own
> service files then each of them will be rediscovering the issues
> themselves, possibly after we've triaged it here for the Nth time. Even
> if the set of upstream service files are not kept completely up to date
> at least they are in a common location, with some >0 chance of getting
> update when things change.
>
> I'm not sure which way I am leaning right now.

Speaking in my capacity as a downstream consumer, I would much prefer
upstream to carry scripts for each init system.

IMO, the benefits of not repeatedly solving the same bug different ways,
and a wider set of eyes checking changes outweigh the problems of things
getting out of sync.

Testing can be trivially gated by running OSS test on different base
distros and strictly not using sysvinit compatibility.

And speaking of upstart, XenServer has some experimental upstart
configuration files for use in a CentOS 6.x environment.  (They should
be on github, but it would appear github is out of date, which I need to
investigate)

~Andrew

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