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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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.

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