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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 05/07/18 17:41, George Dunlap wrote:
>
>> On Jul 5, 2018, at 5:23 PM, Ian Jackson <ian.jackson@xxxxxxxxxx> wrote:
>>
>> Sander Eikelenboom writes ("Re: [Xen-devel] [Notes for xen summit 2018 
>> design session] Process changes: is the 6 monthly release Cadence too short, 
>> Security Process, ..."):
>>> Thursday, July 5, 2018, 5:14:39 PM, you wrote:
>>>> So that means that often, and at least from one test flight to the
>>>> next, all of the base dom0 OS needs to be copied from somewhere else
>>>> to the test host.  This is not currently as fast as it could be, but
>>>> running d-i is not massively slower than something like FAI.
>>> how about using (LVM) snapshotting (whch does COW) and drop the
>>> snapshots after a test ?  Only do a new OS install once a day/week
>>> (or point releas) and only after having an OSSTEST pass ?  That
>>> should have fairly little overhead.
>> I'm sorry to have to say this, but you seem not to have read what I
>> wrote above.
>>
>> Leaving aside other questions about using LVM for a whole machine
>> including possible EFI system partition, bootloader etc., where would
>> the base image be for this LVM snapshot ?
>>
>> If it is on the host itself then the previous test can corrupt it.
>> This is not theoretical: we are doing OS and hypervisor development.
>> Breakage is to be expected.
> What would you think of a “backup partition” scheme instead?  I.e., make 
> (say) /dev/sda1 and /dev/sda2  identical size, install to /dev/sda1, use a 
> small “snapshot” netboot utility to dd it into /dev/sda2.  Run a test, then 
> dd from /dev/sda2 back into /dev/sda1.  If this were only a few gigs it 
> shouldn’t take more than a minute or two.  How long does a full install take?
>
> In theory of course a wild OS write could corrupt something in an unmounted 
> partition, but in practice the chance of that happening in *our* testing 
> seems seems pretty tiny.  (Embedded device manufacturers seem to think this 
> is rare enough to update firmware with, and they have a lot more to lose than 
> we do.)

XenRT, which is XenServers provisioning and testing system and install,
can deploy arbitrary builds of XenServer, or arbitrary builds of various
Linux distros in 10 minutes (although for distros, we limit our install
media to published point releases).  Google "10 minutes to Xen" for some
PR on this subject done back in the day!

This is a fresh install of the host.  Its not hard, and its not rocket
science.  What it is is absolutely necessary for reliable testing.

Attempting to cleverly cache the existing install to avoid reinstalls
won't save you much time, and it will introduce extra complexity, extra
corner cases and inevitably make the problem we're trying to solve even
worse.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel