[Xen-devel] Notes from Xen BoF at Debconf15

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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/

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.

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.

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.

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.

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.

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".

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