[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Xen 4.1.x security support
Thursday, September 19, 2013, 12:41:43 PM, you 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. I don't think crossing future minor version would have to be a problem. The major problem with the current 4.2 and 4.3 minor versions is that they are released in the 'middle' of the major switch of toolstack && qemu-upstream. As a consequence they do have rough edges. >> > >> > 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. There are still some things which are not supported / do not work as documented in the libxl toolstack and/or upstream qemu. Perhaps a testday should be spend on trying and validating all xend && xm && qemu-traditional options on xl && qemu-xen ? Feature parity or at least corresponding documentation would be nice before doing an LTS or bumping the major. >> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |