[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |