Re: [Xen-devel] [stage1-xen PATCH v1 06/10] build/fedora: Add `xen-unstable-runit/*` scripts

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 11/09/2017 21:20, Stefano Stabellini wrote:
> On Sat, 9 Sep 2017, Rajiv Ranganath wrote:
>> On Thu, Sep 07 2017 at 12:10:21 AM, Stefano Stabellini 
>> <sstabellini@xxxxxxxxxx> wrote:
>>
>> [...]
>>
>>> The series is much better now thank you. One question: why did you write
>>> your own init scripts rather than reusing xencommons (with the caveat
>>> that you would have to add make sure to source_path.sh before running
>>> xencommons)?  Does it have something to do with systemd?
>> There are a few related reasons for this.
>>
>> 1. Using runit lets us abstract out our dependency on systemd and
>> upstart. We can use the same abstraction in containers [1], virtual
>> machines and on bare metal.
>>
>> 2. In Linux distributions, there is tight coupling between package
>> management system (rpm/deb), init systems (upstart/systemd), and service
>> daemons.
>>
>> With containers, if the expectation is that most service daemons and
>> apps would be containerized, and managed by a node agent then a natural
>> question to ask would be what should be the role of init systems like
>> systemd?
>>
>> By using runit (on systemd, upstart and within containers), we defer
>> answering this question. 
>>
>> 3. One of the use cases that we want to support is to have different
>> versions of xen co-exist on the same filesystem. Then a higher level
>> tool can do rolling updates and if required rollbacks.
>>
>> While it is possible to accomplish this on existing init systems,
>> depending on how xen is packaged and deployed, it might involve using
>> distro package and repository management tools.
>>
>> With runit, we can use regular docker tools, which is much more friendly
>> for mainstream developers and CI systems. We also abstract over init
>> systems, which is a desirable property to have.
>>
>> 4. I looked into xencommons script and systemd unit files when creating
>> runit scripts. Our runit scripts is straightforward translation of how
>> one would start xen manually.
>>
>> Perhaps the only part of the script that might need some explanation is
>> in `xen-init-dom0/run`.
>>
>> ```
>> exec chpst -b xen-init-dom0 runit-pause
>> ```
>>
>> This is a pattern used to build equivalent of "oneshot" service in
>> systemd. It was developed in Ignite (a Arch Linux project before they
>> switched to systemd) and later co-opted by Void Linux [2].
>>
>> I am not sure if I answered your question. Sometimes I feel, maybe we
>> should just let questions around init systems be like one of those
>> "unanswered questions" in theology. :-) [3]
>>
>> Best,
>> Rajiv
>>
>> [1] https://github.com/lambda-linux/baseimage-amzn#adding_additional_daemons
>>
>> [2] 
>> https://github.com/voidlinux/void-runit/commit/7aecf46ec589a5bc49ae2392137bcd0e7468dd08
> Thank you for the pointers. I have no opinions on the format of the init
> scripts. runit is fine by me in that respect, and I understand the
> advantages you pointed out.
>
> My only concern is about diverging from the upstream Xen codebase. I
> think the runit scripts should call xencommons underneath. If xencommons
> cannot cope with being called from runit, we could make changes to
> xencommon in xen.git to make it so.
>
> Otherwise, we will end up in a situation such as:
> - xen.git changes xencommons
> - we don't notice
> - we upgrade Xen version
> - stage1-xen doesn't work anymore
>
> If we used xencommons underneath we would avoid this, and it looks like
> xencommons could be made to work well with runit.

If possible, upstream Xen should be made to be compatible with runit
(this would be the ideal case).  If not, upstream Xen should contain
different styles of these files, which are selected between by a
./configure option (this is suboptimal, but better than locally
forking).  This offers the greatest chance that updates to one don't
cause the other to be stale.

~Andrew

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