[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [OSSTEST PATCH 23/27] make-flight: Provide xen-unstable-smoke branch
On Wed, 2015-09-16 at 15:51 +0100, Ian Jackson wrote: > Ian Campbell writes ("Re: [OSSTEST PATCH 23/27] make-flight: Provide xen > -unstable-smoke branch"): > > On Wed, 2015-09-16 at 14:35 +0100, Ian Jackson wrote: > > > This contains a very limited set of jobs: > > > build-amd64 > > > build-armhf > > > test-amd64-amd64-libvirt > > > test-amd64-amd64-xl-qemuu-debianhvm-i386 > > > test-armhf-armhf-xl > > > > > > The debianhvm job exists only in this flight, and is generated by > > > having branch_debianhvm_arch return i386 instead of amd64. > > > > any particular reason for this? > > I wanted to test at least one 32-bit guest. I have added a note about > this to the commit message. OK. I wonder if we should also add this to the regular flights? Seems odd to smoke test it for unstable but not for e.g. real 4.6 flights. > > > Deployment note: This requires images/debian-7.2.0-i386-CD-1.iso > > > which I have already downloaded to the Cambridge instance using > > > jigdo. > > > > But not the main colo? > > Not yet. I will do that before I start trying to run this there. I > think I ought to do such a --real run, by hand, when the series seems > about ready to go into pretest. > > > > +case "$branch" in > > > +xen-unstable-smoke) > > > + global_runvars+=" hostalloc_maxbonus_variation~=0 " > > > + global_runvars+=" hostalloc_bonus_previousfail~=0 " > > > > Why are these synthetic? > > I wrote in the commit message that introduced the ~ notation in > cs-job-create: > > This will be useful if we want to set hostalloc_* runvars. Normally > we would want to set those only on flights generated by make-flight. > > Flights generated by cs-bisection-step or cs-adjust-flight ought not > to copy them, because cs-bisection-step makes its own arrangements > for > host specification, as should the caller of cs-adjust-flight (perhaps > via the blessing system). > > Using `synth' for this is arguably slightly wrong but it does the > right thing in all existing cases. The alternative would be a schema > change. > > Perhaps I should move some of this text to this commit message. Yes, I'd forgotten all about it by now, which I think it is when it is relevant. > > Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |