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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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.

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