Re: [Xen-devel] Xen 4.1.x security support

[Pasi Kärkkäinen <pasik@xxxxxx>]

On Wed, Sep 18, 2013 at 04:42:05PM +0100, George Dunlap wrote:
> On Wed, Sep 18, 2013 at 2:49 PM, Andres Lagar-Cavilla
> <andreslc@xxxxxxxxxxxxxx> wrote:
> >> On 09/18/13 10:39, Jan Beulich wrote:
> >>>>>> On 17.09.13 at 19:44, Joanna Rutkowska <joanna@xxxxxxxxxxxxxxxxxxxxxx> 
> >>>>>> wrote:
> >>>> And a somehow more general thought: what most people expect from
> >>>> baremetal hypervisors, I think, is stability. Unlike the Linux kernel,
> >>>> the Xen hypervisor does not need to support each and every device
> >>>> invented on the planet, each and every possible filesystem, or
> >>>> networking stack, etc. That's, in fact, (one of) the biggest advantage
> >>>> of a hypervisor over a monolithic kernel. So, why, oh why, such a race
> >>>> to keep bumping the major version over and over again?
> >>>
> >>> In fact I'm the (so far apparently only) one trying to stop further
> >>> accelerating the release schedule from its original 9 month cycle.
> >>> I don't recall you having chimed in when the release schedule for
> >>> 4.4 in particular and the shortening of the release cycle in general
> >>> was discussed on the mailing list. There were arguments in favor
> >>> of the shortening which I certainly appreciate.
> >>>
> >>
> >> Well, I'm not regular on xen-devel, because I'm not a Xen developer,
> >> really. I'm a _user_ of Xen. In an ideal world we (Qubes OS project)
> >> should not even maintain a fork of Xen, nor be at xen-devel at all.
> >>
> >> I just came here now because I'm worried that the team I'm leading, the
> >> users of Xen, will now need to spend considerable amount of time on
> >> upgrading our product to Xen 4.2, because Xen 4.1 security support is
> >> ending soon.
> >
> > Several communities are adopting the notion of LTS releases. Ubuntu 
> > Precise, for example, has been a major enabler in Openstack by offering a 
> > steady platform for over 18 months now. Upstream kernel 3.10 is slated to 
> > underpin major distros for a good while.
> >
> > I don't see why xen.org could not offer a similar cadence, and all the down 
> > streams would naturally align to that.
> >
> > Jan's point about keeping many stable trees being a significant time sink 
> > is extremely valid.
> >
> > I think the LTS solutions solves both of your problems. As a downstream, 
> > Qubes won't have to move rapidly crossing minor versions. There will be a 
> > reckoning day when transitioning to the next LTS, but you will have plenty 
> > of advance notice to prepare.
> >
> > The stable tree maintainer needs to care about a single tree which is a 
> > very well known quantity, and not have to deal with maybe two or even three 
> > trees at a time.
> >
> > One could argue that an LTS approach lessens the value of non LTS releases. 
> > In fact, discussions in Ubuntu have pointed at forgetting about non LTS 
> > releases and doing nightly builds in between, given a strong enough CI/CD 
> > environment. I for one think that's a bit too drastic and there is value to 
> > 4.3, 4.4, etc marking completion of important features.
> >
> > If we were to appoint an LTS, I would vote for 4.2, which saw a significant 
> > delta with respect to 4.1.
> >
> > If we were to appoint a 5.0, that would be a prime candidate for an LTS. 
> > Xend deprecation as well as fully-baked PVH would be two major milestones 
> > demarcating a clear before and after.
> 
> Yes, I think we will need to go to designating a "stable hypervisor"
> that will be supported for longer periods of time.  One aspect of
> which one would be the best at this point is how many downstreams we
> have using which release.  Debian, Ubuntu, and XenServer, for
> instance, have older versions that use 4.1, I believe.  I'm not sure
> how many downstreams we have using 4.2.
> 

At least the following rpm-based distros are currently shipping with Xen 4.2:

- Fedora 19
- CentOS6 Xen (not part of the distro, provided separately).


-- Pasi

> But this should be discussed in a way that will make sure all the
> stakeholders are involved.
> 
>  -George
> 


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