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

[Stefan Bader <stefan.bader@xxxxxxxxxxxxx>]

On 18.09.2013 10:42, 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.

Precise/12.04 is 4.1 based. Quantal/12.10 as well. Raring/13.04 is 4.2 based
(though its not a LTS release). I am trying to get all of them follow the
matching Xen stable releases during their life-time. The next LTS should have
Xen 4.3. So solely from my point of view selecting 4.3 as a Xen LTS would work
better but then I know this just started to introduce some quite big(ger)
changes and probably from the Xen side a later version would work better.

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

Attachment: signature.asc
Description: OpenPGP digital signature

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