Re: [Xen-devel] [OSSTEST PATCH 23/27] make-flight: Provide xen-unstable-smoke branch

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

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

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel