Re: [Xen-devel] [PATCH osstest v4] Add libvirt build and test jobs.

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-04-22 at 14:47 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH osstest v4] Add libvirt build and test jobs."):
> > [stuff]
> 
> Thanks.
> 
> > diff --git a/ap-push b/ap-push
> > index dc0a166..c3359fc 100755
> ...
> > +libvirt-gnulib)
> > +   # No gate
> > +   exit 1
> 
> This would result in a mysterious failure.  You probably need to add
> a suitable echo >&2.

OK.

> > diff --git a/mfi-common b/mfi-common
> > index 598aa02..503a1fc 100644
> > --- a/mfi-common
> > +++ b/mfi-common
> ...
> > +                tree_libvirt_gnulib=$TREE_LIBVIRT_GNULIB revision_libv\
> irt_gnulib=$REVISION_LIBVIRT_GNULIB\
> > +                ${TREEVCS_LIBVIRT_GNULIB:+treevcs_libvirt_gnulib=}${TR\
> EEVCS_LIBVIRT_GNULIB}
> 
> I was concerted about the "_" in "*_libvirt_gnulib" for the runvar
> names.  I haven't been able to find anything which will actually break
> due to the intervening "_" and a search of the db does produce some
> old flights which mention a tree_linux_pq.
> 
> I think we should go with this because the alternatives are too ugly
> but we should watch for breakage.

OK.

> Also, I wonder if "tree_gnulib_libvirt" would be more in keeping with
> our naming scheme.  (cf "BLAH_LINUX_ARM".)

I'm ok with either.

> 
> The rest of it looks plausible apart from this:
> 
> > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > index 65afc5b..99b313e 100644
> > --- a/Osstest/TestSupport.pm
> > +++ b/Osstest/TestSupport.pm
> > @@ -1776,7 +1776,13 @@ our %toolstacks=
> >          Command => 'xl',
> >          CfgPathVar => 'cfgpath',
> >     RestoreNeedsConfig => 1,
> > -        }
> > +        },
> > +     'libvirt' => {
> > +        NewDaemons => [qw(libvirtd)],
> > +        Dom0MemFixed => 1,
> > +        Command => 'virsh',
> > +        ExtraPackages => [qw(libnl1 libavahi-client3)],
> > +        },
> >       );
> 
> This is obviously not going to work.

Correct.

> Do you intend for this to just
> fail in ridiculous ways, and provide a general abstraction later ?

Yes. The test job runs up into ts-guest-start which fails as expected. I
figured that fixing that could come later, probably via an abstraction
layer as you suggest.

Ian.



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