[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Notes for xen summit 2018 design session] Process changes: is the 6 monthly release Cadence too short, Security Process, ...

  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxx>
  • From: Juergen Gross <jgross@xxxxxxxx>
  • Date: Thu, 5 Jul 2018 14:20:11 +0200
  • Autocrypt: addr=jgross@xxxxxxxx; prefer-encrypt=mutual; keydata= xsBNBFOMcBYBCACgGjqjoGvbEouQZw/ToiBg9W98AlM2QHV+iNHsEs7kxWhKMjrioyspZKOB ycWxw3ie3j9uvg9EOB3aN4xiTv4qbnGiTr3oJhkB1gsb6ToJQZ8uxGq2kaV2KL9650I1SJve dYm8Of8Zd621lSmoKOwlNClALZNew72NjJLEzTalU1OdT7/i1TXkH09XSSI8mEQ/ouNcMvIJ NwQpd369y9bfIhWUiVXEK7MlRgUG6MvIj6Y3Am/BBLUVbDa4+gmzDC9ezlZkTZG2t14zWPvx XP3FAp2pkW0xqG7/377qptDmrk42GlSKN4z76ELnLxussxc7I2hx18NUcbP8+uty4bMxABEB AAHNHkp1ZXJnZW4gR3Jvc3MgPGpncm9zc0BzdXNlLmRlPsLAeQQTAQIAIwUCU4xw6wIbAwcL CQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJELDendYovxMvi4UH/Ri+OXlObzqMANruTd4N zmVBAZgx1VW6jLc8JZjQuJPSsd/a+bNr3BZeLV6lu4Pf1Yl2Log129EX1KWYiFFvPbIiq5M5 kOXTO8Eas4CaScCvAZ9jCMQCgK3pFqYgirwTgfwnPtxFxO/F3ZcS8jovza5khkSKL9JGq8Nk czDTruQ/oy0WUHdUr9uwEfiD9yPFOGqp4S6cISuzBMvaAiC5YGdUGXuPZKXLpnGSjkZswUzY d9BVSitRL5ldsQCg6GhDoEAeIhUC4SQnT9SOWkoDOSFRXZ+7+WIBGLiWMd+yKDdRG5RyP/8f 3tgGiB6cyuYfPDRGsELGjUaTUq3H2xZgIPfOwE0EU4xwFgEIAMsx+gDjgzAY4H1hPVXgoLK8 B93sTQFN9oC6tsb46VpxyLPfJ3T1A6Z6MVkLoCejKTJ3K9MUsBZhxIJ0hIyvzwI6aYJsnOew cCiCN7FeKJ/oA1RSUemPGUcIJwQuZlTOiY0OcQ5PFkV5YxMUX1F/aTYXROXgTmSaw0aC1Jpo w7Ss1mg4SIP/tR88/d1+HwkJDVW1RSxC1PWzGizwRv8eauImGdpNnseneO2BNWRXTJumAWDD pYxpGSsGHXuZXTPZqOOZpsHtInFyi5KRHSFyk2Xigzvh3b9WqhbgHHHE4PUVw0I5sIQt8hJq 5nH5dPqz4ITtCL9zjiJsExHuHKN3NZsAEQEAAcLAXwQYAQIACQUCU4xwFgIbDAAKCRCw3p3W KL8TL0P4B/9YWver5uD/y/m0KScK2f3Z3mXJhME23vGBbMNlfwbr+meDMrJZ950CuWWnQ+d+ Ahe0w1X7e3wuLVODzjcReQ/v7b4JD3wwHxe+88tgB9byc0NXzlPJWBaWV01yB2/uefVKryAf AHYEd0gCRhx7eESgNBe3+YqWAQawunMlycsqKa09dBDL1PFRosF708ic9346GLHRc6Vj5SRA UTHnQqLetIOXZm3a2eQ1gpQK9MmruO86Vo93p39bS1mqnLLspVrL4rhoyhsOyh0Hd28QCzpJ wKeHTd0MAWAirmewHXWPco8p1Wg+V+5xfZzuQY0f4tQxvOpXpt4gQ1817GQ5/Ed/wsDtBBgB CAAgFiEEhRJncuj2BJSl0Jf3sN6d1ii/Ey8FAlrd8NACGwIAgQkQsN6d1ii/Ey92IAQZFggA HRYhBFMtsHpB9jjzHji4HoBcYbtP2GO+BQJa3fDQAAoJEIBcYbtP2GO+TYsA/30H/0V6cr/W V+J/FCayg6uNtm3MJLo4rE+o4sdpjjsGAQCooqffpgA+luTT13YZNV62hAnCLKXH9n3+ZAgJ RtAyDWk1B/0SMDVs1wxufMkKC3Q/1D3BYIvBlrTVKdBYXPxngcRoqV2J77lscEvkLNUGsu/z W2pf7+P3mWWlrPMJdlbax00vevyBeqtqNKjHstHatgMZ2W0CFC4hJ3YEetuRBURYPiGzuJXU pAd7a7BdsqWC4o+GTm5tnGrCyD+4gfDSpkOT53S/GNO07YkPkm/8J4OBoFfgSaCnQ1izwgJQ jIpcG2fPCI2/hxf2oqXPYbKr1v4Z1wthmoyUgGN0LPTIm+B5vdY82wI5qe9uN6UOGyTH2B3p hRQUWqCwu2sqkI3LLbTdrnyDZaixT2T0f4tyF5Lfs+Ha8xVMhIyzNb1byDI5FKCb
  • Cc: Lars Kurth <lars.kurth@xxxxxxxxxx>, "advisory-board@xxxxxxxxxxxxxxxxxxxx" <advisory-board@xxxxxxxxxxxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, Rich Persaud <persaur@xxxxxxxxx>, "committers@xxxxxxxxxxxxxx" <committers@xxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Matt Spencer <Matt.Spencer@xxxxxxx>
  • Delivery-date: Thu, 05 Jul 2018 12:20:26 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Openpgp: preference=signencrypt

On 05/07/18 13:51, Andrew Cooper wrote:
> On 05/07/18 12:18, George Dunlap wrote:
>>>>    Another potential problems showed up last week: OSSTEST is using the
>>>>    Debian servers for doing the basic installation. A change there (e.g.
>>>>    a new point release) will block tests. I'd prefer to have a local cache
>>>>    of the last known good set of *.deb files to be used especially for the
>>>>    branched Xen versions. This would rule out remote problems for releases.
>>>> This is again something which we should definitely look at.
>>> This was bad luck.  This kind of update happens about 3-4 times a
>>> year.  It does break everything, leading to a delay of a day or two,
>>> but the fix is straightforward.
>>> Obviously this is not ideal but the solutions are nontrivial.  It is
>>> not really possible to "have a local cache of the last known good set
>>> of *.deb files" without knowing what that subset should be; that would
>>> require an edifice to track what is used, or some manual configuration
>>> which would probably break.  Alternatively we could run a complete
>>> mirror but that is a *lot* of space and bandwidth, most of which would
>>> be unused.
>>> I think the right approach is probably to switch from using d-i for
>>> host installs, to something like FAI.  That would be faster as well.
>>> However that amouns to reengineering the way osstest does host
>>> installs; it would also leave us maintaining an additional way to do
>>> host installs, since we would still want to be able to *test* d-i
>>> operation as a guest.
>> What I think would be ideal is a way to take ‘snapshots’ of different states 
>> of setup for various hosts and revert to them.  There’s absolutely no reason 
>> to do a full install of a host every osstest run, when that install happens 
>> 1) before we even install Xen, and 2) should be nearly identical each time.  
>> We should be able to install a host, take a snapshot of the “clean” install, 
>> then do the build prep, take a snapshot of that, and then simply revert to 
>> one or both of those (assuming build requirements haven’t changed in the 
>> mean time) whenever necessary.  Re-generating these snapshots once per week 
>> per host should be plenty, and sounds like it would massively improve the 
>> current throughput.
>> I’d like to propose the idea also that we try to find a more efficient way 
>> of testing guest functionality than doing a guest install.  I understand 
>> it’s a natural way to test a reasonable range of functionality, but 
>> particularly for Windows guests, my impression is that it’s very slow; there 
>> must be a way to make a test that would have similar coverage but be able to 
>> be completed with a pre-installed snapshot, in only a few minutes.
> We've had similar discussions in XenServer. That idea is superficially
> attractive but actually makes things worse, because it now means that
> filesystem clone/snapshot is now in the mix of things which can go wrong.
> Particularly with OSSTest testing mainline kernels, rather than distro
> stable kernels, the chances of finding filesystem bugs grows
> substantially, and the complexity of diagnosing an issue is outside of
> our area of expertise.

But are really all tests required to use a freshly installed mainline
kernel? Can't we e.g. do a guest install test once a new kernel is
released and clone the resulting guest disk image for other tests
(after shutting down the guest, of course)?

Same applies to the host: the base system (without the to be tested
component like qemu, xen, or whatever) could be installed just by
cloning a disk/partition/logical volume.

Each image would run through the stages new->staging->stable:

- Each time a component is released an image is based on (e.g. a new
  mainline kernel) a new image is created by installing it. In case this
  succeeds, the image is moved to the staging area.
- The images in the staging area are tested using known stable
  components in order to test the image, not the test-components. In
  case of all tests succeeded the image is moved to the stable area.
- The stable images are used to test components from staging. In case of
  success the related components can be pushed to stable/master.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.