Re: [Xen-devel] Notes from Xen BoF at Debconf15

[Doug Goldstein <cardoe@xxxxxxxxxx>]

On 9/8/15 4:24 AM, Ian Campbell wrote:
> Xen upstream BoF
> ================
> 
> We had a discussion around Xen and packaging at Debian's annual developer
> conference (Debconf) a few weeks back:
> https://summit.debconf.org/debconf15/meeting/279/xen-upstream-bof/

While I'm not a Debian guy and was not at debconf I hope maybe I can
share some of my comments on packaging Xen from a different POV however.
I've been a Gentoo dev for over a decade and I've played around with
improving Xen's packaging in Gentoo. Also I have as of late been
updating Yocto's Xen packages to try to make those work.

> 
> These are my notes, I think there is probably stuff of interest to most
> distro people, not just Debian folks.
> 
> The session was scheduled in a small, out of the way, room. Around 2
> dozen people attended including:
> 
>   Ian Jackson
>   Bastian Blank ("waldi", current Xen package maintainer in Debian)
>   Guido Trotter (previous Xen package maintainer, who still takes care
>                  of stable security updates)
>   Axel Beckert  (maintainer of the xen-tools helpers)
>   Various users
>   Myself
> 
> The majority of the conversation was between Ian & I and Bastian and
> Guido, some users raised some issues towards the end.
> 
> Embedding in xen.git
> ====================
> 
> We are much better about providing ways to use system-supplied
> components these days (since 4.4) and Debian uses them.

100% here. Most distros hate this since its against their policy and
fight real hard to break this apart. I'm hoping to throw my efforts
behind raisin and get Xen upstream to embrace raisin to build rather
than embedding bits.

> 
> Waldi noted that iPXE did not have such an option. Since that iPXE is
> only used by qemu-trad (for qemu-upstream the iPXE comes from the PCI
> ROM BAR) and Debian disabled qemu-trad it should be pretty quick to
> patch the build system to disable iPXE.

This would be a welcome addition.

> 
> Secondly it was noted that SeaBIOS is still built into hvmloader,
> which makes package updates harder (needs a binNMU of the Xen package
> to pickup a new SeaBIOS). Since this is in guest context it is not an
> issue for the security team (which would make it higher priority) and
> there are medium term plans to perhaps make it possible to load the
> BIOS via the toolstack instead.
> 
> Note that OVMF would also be built in but is non-free and hence
> disabled.
> 
> Lowlevel library API stability
> ==============================
> 
> The majority of the current Debian patch queue is moving unstable
> libraries (mainly libxc) from $libdir to $libexecdir/xen-X.Y, adding
> -rpath where needed and removing the SONAME from such libraries. Also
> move related binary files.

This would be good to upstream. If the libraries are not meant to have
API stability then they should likely relocate there.

> 
> Waldi expressed hope that the hypervisor interfaces could become
> stable, but we think this is unlikely. Having the hypervisor provide a
> compat layer for older interfaces was ruled out as the wrong place
> from a security PoV. Second choice would be to have the tools provide
> a compat layer for older hypervisors, which would be possible but
> perhaps tricky to achieve.
> 
> This is also a problem for some third packages, e.g. qemu-upstream and
> kexec-tools. This requires a binNMU of those packages to build against
> a new Xen package. This is painful for maintainers.
> 
> We explained our plan was to move some sections of the unstable
> library out into small stable libraries for specific purposes, with
> stuff needed for qemu-upstream, kexec-tools and other external
> packages being a priority in the short term. After this we plan to
> reexamine what is left and consider next steps.
> 
> In the meantime it should be much easier these days to provide
> upstream configure options to provide the changes currently patched in
> by Debian.
> 
> Midlevel library stability
> ==========================
> 
> libxenlight is only API not ABI stable. This is a pain in particular
> for libvirt which needs binNMU for new Xen package.
> 
> We would like to eventually offer ABI stability or this library, but
> we are not there yet.

What about doing symbol versioning like libvirt does to start offering
ABI stability? You could then at some point in the future do a ABI break
to remove out the bits that were deprecated when you do the "1.0" release.


> 
> Stubdomains
> ===========
> 
> Hard to do in a packaging environment (is really its own partial
> architecture). Rump kernels are no different in this regard.
> 
> No clever ideas were put forward.

Honestly what about moving these more out of tree? Now with mini-os
being out of tree and the stubdoms needing mini-os its an absolute mess
to build from a distro standpoint since mini-os is git fetched. To make
it work upstream using raisin would be a great improvement here.


> 
> initscripts
> ===========
> 
> Debian has its own initscripts, does not use the upstream ones.
> 
> Waldi stated this was because the upstream ones were not properly LSB
> and were too "cross-distro".

It would likely been useful to stick a README in with the init scripts
that are in the tree to identify how they should be used together.
Ubuntu currently (I assume Debian too) uses 1 LSB script and the rest
systemd scripts which doesn't always do the right thing (at least on my
machine) so I would say the situation as a whole needs to be improved.

> 
> We would like to try and have these in xen.git. Perhaps a Yakk, but
> closer to upstream the better. Not a very high priority though.
> 
> grub-xen
> ========
> 
> Needs much better docs.
> 
> ACTION: I agreed to move the text of my blog post somewhere more
> obvious.
> 
> Release cycle
> =============
> 
> Waldi commented that the stable release cycle was too long. Would like
> to see a release after any large security update.
> 
> We asked if the RCs for stable releases were valuable, the answer was
> "not so much".
> 
> Waldi would prefer to avoid cherry-picking security fixes if possible.
> 
> We asked if we thought Xen stable releases could be added to Debian
> point releases. Waldi thought they likely could be, citing the
> inclusion of Linux stable releases in point releases.
> 
> Our stable releases follow a similar set of rules to Linux, we think
> we implement them more faithfully (less feature or feature-like
> backports)
> 
> ACTION: Talk to Jan about making changes to stable release process.
> 
> Security updates
> ================
> 
> Guido asked if security updates could go back further.
> 
> Currently we go to 4.2, but Debian Wheezy has Xen 4.1.
> 
> The security team don't currently have the effort to go further, but
> have recently introduced a private discussion list where predisclosure
> members are encouraged to exchange their own backports.
> 
> Guido is not on global team@xxxxxxxxxxxxxxxx We suggested he discuss
> with the Debian security team switching to a xen specific alias
> including team@ + relevant package maintainers.
> 
> Release schedule vs. migration N=>N+1 support
> =============================================
> 
> Philip Hahn (a user) asked what happens to migration if the release
> cycle shortens.
> 
> We answered that this N=>N+1 policy would need rethinking into an N=>N+M.
> 
> We agreed that it would be useful if M was > Debian release cycle (~2
> years).
> 
> Recent rewrite of migration support has made changing this policy far
> more plausible.
> 
> It was suggested as an aside that using -backports more would be
> useful.
> 
> Remus
> =====
> 
> A user (Kai ???) was interested in Remus support.
> 
> We briefly discussed status, we think it should be reasonably easy to
> combine xl remus into one of the HA systems in Debian (e.g. Pacemaker,
> linux-ha?)
> 
> Ferenc Wagner pointed out that integrating VMs (non-HA style) into a
> pacemake system was quite easy.
> 
> Testing Xen in KVM
> ==================
> 
> A user (anon) asked if we tested this, because it sometimes broke.
> 
> We only test Xen in Xen, pointed to the wiki page.
> 
> OpenStack/xapi in Debian
> ========================
> 
> I spoke to a couple of users through the week who were asking after
> the future of xapi in Debian, because they wanted OpenStack.
> 
> I was able to point them to the libvirt+XenProject stuff and explained
> about the CI loop etc and they went away happy.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
> 


-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

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