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

[Sander Eikelenboom <linux@xxxxxxxxxxxxxx>]

Thursday, July 5, 2018, 5:14:39 PM, you wrote:

> Juergen Gross writes ("Re: [Xen-devel] [Notes for xen summit 2018 design 
> session] Process changes: is the 6 monthly release Cadence too short, 
> Security Process, ..."):
>> 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.

> Certainly it would be a bad idea to use anything *on the test host
> itself* as a basis for a subsequent test.  The previous test might
> have corrupted it.

> 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.

--
Sander

> To a fairly large extent, similar considerations apply to guest
> images.

>> 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.

> This would happen a lot more often than you seem to image.  "Releaed"
> here really means "is updated in its appropriate git branch".

> Unless you think we should do our testing of Xen mainly with released
> versions of Linux stable branches (in which case, given how Linux
> stable branches are often broken, we might be long out of date), or
> our testing of Linux only with point releases of Xen, etc.

> The current approach is mostly to take the most recent
> tested-and-working git commit from each of the inputs.  This aspect of
> osstest generally works well, I think.

> Ian.




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