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

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On Jul 5, 2018, at 6:02 PM, Ian Jackson <ian.jackson@xxxxxxxxxx> wrote:
> 
> Andrew Cooper writes ("Re: [Xen-devel] [Notes for xen summit 2018 design 
> session] Process changes: is the 6 monthly release Cadence too short, 
> Security Process, ..."):
>> 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!
> 
> osstest's d-i runs take more like 15 minutes.  As I say, this could be
> improved by using something like FAI, but by a factor of at most 2 I
> think.

I figure a dd from a backup partition couldn’t take more than 2 minutes.  So 
obviously we need to apply Amdahl’s law here. So what’s the total percentage of 
time spent doing host installs now, if you had to guess?  If it’s something 
like 5%, then yeah, 15 -> 2 will save you a bit but not much.  If it’s closer 
to 50%, then you’re talking a much more significant savings from avoiding the 
re-install.

>  Instead of working on that, I have been working on reusing an
> install when it is feasible to do so: specifically, after a passing
> job and when the host is to be reused by the same flight, with an
> identical configuration.

I don’t really understand why you’re more worried about a test corrupting a 
backup partition or LVM snapshot, than of a test corrupting a filesystem even 
when the test actually passed.  I don’t have the same experience you do, but it 
seems like random stuff left over from a previous test — even if the test 
passes — would have more of a chance of screwing up a future test than some 
sort of corruption of an LVM snapshot, and even less so a backup partition.

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