From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Bader Subject: Re: Xen 4.1.x security support Date: Thu, 19 Sep 2013 10:55:42 -0500 Message-ID: <523B1E7E.2040207@canonical.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8918052505575114574==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: Ian Campbell , Joanna Rutkowska , Andres Lagar-Cavilla , Ian Jackson , "xen-devel@lists.xen.org" , " Beulich" List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============8918052505575114574== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig4142D15566877B61B29A8DEA" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4142D15566877B61B29A8DEA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 18.09.2013 10:42, George Dunlap wrote: > On Wed, Sep 18, 2013 at 2:49 PM, Andres Lagar-Cavilla=20 > wrote: >>> On 09/18/13 10:39, Jan Beulich wrote: >>>>>>> On 17.09.13 at 19:44, Joanna Rutkowska >>>>>>> wrote: >>>>> And a somehow more general thought: what most people expect from=20 >>>>> 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? >>>>=20 >>>> 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. >>>>=20 >>>=20 >>> 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. >>>=20 >>> I just came here now because I'm worried that the team I'm leading, t= he=20 >>> users of Xen, will now need to spend considerable amount of time on=20 >>> upgrading our product to Xen 4.2, because Xen 4.1 security support is= =20 >>> ending soon. >>=20 >> Several communities are adopting the notion of LTS releases. Ubuntu >> Precise, for example, has been a major enabler in Openstack by offerin= g a >> steady platform for over 18 months now. Upstream kernel 3.10 is slated= to >> underpin major distros for a good while. >>=20 >> I don't see why xen.org could not offer a similar cadence, and all the= down >> streams would naturally align to that. >>=20 >> Jan's point about keeping many stable trees being a significant time s= ink >> is extremely valid. >>=20 >> I think the LTS solutions solves both of your problems. As a downstrea= m, >> Qubes won't have to move rapidly crossing minor versions. There will b= e a >> reckoning day when transitioning to the next LTS, but you will have pl= enty >> of advance notice to prepare. >>=20 >> 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. >>=20 >> One could argue that an LTS approach lessens the value of non LTS rele= ases. >> In fact, discussions in Ubuntu have pointed at forgetting about non LT= S >> 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 val= ue to >> 4.3, 4.4, etc marking completion of important features. >>=20 >> If we were to appoint an LTS, I would vote for 4.2, which saw a signif= icant >> delta with respect to 4.1. >>=20 >> If we were to appoint a 5.0, that would be a prime candidate for an LT= S. >> Xend deprecation as well as fully-baked PVH would be two major milesto= nes >> demarcating a clear before and after. >=20 > Yes, I think we will need to go to designating a "stable hypervisor" th= at > 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 versi= ons > that use 4.1, I believe. I'm not sure how many downstreams we have usi= ng > 4.2. Precise/12.04 is 4.1 based. Quantal/12.10 as well. Raring/13.04 is 4.2 ba= sed (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.= >=20 > But this should be discussed in a way that will make sure all the=20 > stakeholders are involved. >=20 > -George >=20 > _______________________________________________ Xen-devel mailing list = > Xen-devel@lists.xen.org http://lists.xen.org/xen-devel >=20 --------------enig4142D15566877B61B29A8DEA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBCgAGBQJSOx5+AAoJEOhnXe7L7s6jpkUP/jTUPc1/RCFPoPXmPK0rE9V8 R808cmsjaJvZyZZH5EtRTFjJmfjWKJ1bwdLzMCO0jEuioUrnBE/w+dLEM5E003PA MfXWLaamGbme3dsOi+0Lefcva8+j+iUSMOAVcx2oko6vjoGVUcXMV+g9/b7lijAq EUqUUqRMWyPXLnuV1NeaEv306EOxtSqPSQ907JfLmBcAlryaw2EJ4fOp/0susHxg mmloi0YbKwo/36yGFkHm/qTcQnBfOF8faASn5Uaz5zRVDg7Aub+hVntQL8UzUu+X NZMcjb2gCJGCXDoAh2NNQntG7e3/jtzfEH1dFjOZt9X7ygi5lEMpLVVd5ekjRU5W rfuER7XCcPbM2Y+Ra2wH5E3mM2w0nwuPsuKSQ+21E6SDfCFfqsG+/RIiPhYx55xS 8Rrf+0N7xe43b+EjZ8URRGy5mPDWsXmbie8ztvSlkET9UOoPnMcD5MNCLWVwohwn XCEqWdDCDFKTxUCt7kv2OSdsNbEyacdbCZ5/9LRv9RXw9SsX+l6TF/hj25CvYAPa VBmVWQlqItDeDsUUe+ADy+ArG4/lfSwzqHgOyG+O5D/iI0Fj+DqLU9/TiqI48dCj eJZfnOyGOegTF9ZTleQgNEX7+PVfhclf2gP7gcNR0eToohW1BAj0rJYsIzD337FR osyQIMf5w7yyKVTLRxE4 =kOtJ -----END PGP SIGNATURE----- --------------enig4142D15566877B61B29A8DEA-- --===============8918052505575114574== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============8918052505575114574==--