[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





On Thu, 19 Sep 2013, Pasi Kärkkäinen wrote:

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

Though Fedora 20 will ship with Xen 4.3. The last Fedora version with Xen 4.1 was Fedora 17 which is now out of support.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.