All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Bader <stefan.bader@canonical.com>
To: George Dunlap <George.Dunlap@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>,
	Andres Lagar-Cavilla <andreslc@gridcentric.ca>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	"<jbeulich@suse.com> Beulich" <JBeulich@suse.com>
Subject: Re: Xen 4.1.x security support
Date: Thu, 19 Sep 2013 10:55:42 -0500	[thread overview]
Message-ID: <523B1E7E.2040207@canonical.com> (raw)
In-Reply-To: <CAFLBxZY9=R6EA-1pGCVEmia_MrbC1wtedouCQ8h3B4q0wFgaow@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 4495 bytes --]

On 18.09.2013 10:42, George Dunlap wrote:
> On Wed, Sep 18, 2013 at 2:49 PM, Andres Lagar-Cavilla 
> <andreslc@gridcentric.ca> wrote:
>>> On 09/18/13 10:39, Jan Beulich wrote:
>>>>>>> On 17.09.13 at 19:44, Joanna Rutkowska
>>>>>>> <joanna@invisiblethingslab.com> 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@lists.xen.org http://lists.xen.org/xen-devel
> 



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 899 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

  parent reply	other threads:[~2013-09-19 15:55 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.9883.1379496660.32487.xen-devel@lists.xen.org>
2013-09-18 13:49 ` Xen 4.1.x security support Andres Lagar-Cavilla
2013-09-18 15:42   ` George Dunlap
2013-09-19 10:41     ` Pasi Kärkkäinen
2013-09-19 11:23       ` Sander Eikelenboom
2013-09-19 12:09       ` Jan Beulich
2013-09-20  8:12       ` M A Young
2013-09-19 15:55     ` Stefan Bader [this message]
2013-09-16 22:01 Marek Marczykowski-Górecki
2013-09-17  6:47 ` Jan Beulich
2013-09-17 17:38   ` Joanna Rutkowska
2013-09-17 17:44     ` Joanna Rutkowska
2013-09-17 19:18       ` Ian Campbell
2013-09-17 19:55         ` Joanna Rutkowska
2013-09-17 20:36           ` Marek Marczykowski-Górecki
2013-09-17 20:50             ` Ian Campbell
2013-09-17 20:46           ` Ian Campbell
2013-09-18 10:03           ` Vincent Hanquez
2013-09-18 10:08             ` Joanna Rutkowska
2013-09-18  8:39       ` Jan Beulich
2013-09-18  8:50         ` Joanna Rutkowska
2013-09-18  9:19         ` Sander Eikelenboom
2013-09-18 15:50           ` George Dunlap
2013-09-18  8:33     ` Jan Beulich
2013-09-18  8:37       ` Joanna Rutkowska
2013-09-18  8:50         ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=523B1E7E.2040207@canonical.com \
    --to=stefan.bader@canonical.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=andreslc@gridcentric.ca \
    --cc=ian.campbell@citrix.com \
    --cc=joanna@invisiblethingslab.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.