Open Stack

On Wed, Nov 18, 2015 at 05:18:28PM +1100, Tony Breeds wrote:
> On Tue, Nov 17, 2015 at 03:32:45PM -0800, Jay Pipes wrote:
> > On 11/17/2015 11:10 AM, Markus Zoeller wrote:
> > >Background
> > >==========
> > >The blueprint [1] wants to utilize the *virtlogd* logging deamon from
> > >libvirt. Among others to solve bug [2], one of our oldest ones. The
> > >funny part is, that this libvirt feature is still in development. This
> > >was a trigger to see if we can create a gate job which utilizes the
> > >latest, bleeding edge, version of libvirt to test such features. We
> > >discussed it shortly in IRC [3] (tonyb, bauzas, markus_z) and wanted to
> > >get some feedback here. The summary of the idea is:
> > >* Create a custom repo which contains the latest libvirt version
> > >* Enhance Devstack so that it can point to a custom repo to install
> > >   the built libvirt packages
> > >* Have a nodepool image which is compatible with the libvirt packages
> > >* In case of [1]: check if tempest needs further/changed tests
> > >
> > >Open questions
> > >==============
> > >* Is already someone working on something like that and I missed it?
> > 
> > Sean (cc'd) might have some information on what he's doing in the OVS w/
> > DPDK build environment, which AFAIK requires a later build of libvirt than
> > available in most distros.
> > 
> > >* If 'no', is there already a repo which contains the very latest
> > >   libvirt builds which we can utilize?
> > >
> > >I haven't done anything with the gates before, which means there is a
> > >very high chance I'm missing something or missunderstanding a concept.
> > >Please let me know what you think.
> > 
> > A generic "build libvirt or OVS from this source repo" dsvm job would be
> > great I think. That would allow overrides in ENV variables to point the job
> > to a URI for grabbing sources of OVS (DPDK OVS, mainline OVS) or libvirt
> > that would be built into the target nodepool images.
> 
> I was really hoping to decouple the build from the dsvm jobs.  My initial
> thoughts were a add a devstack plugin that add $repo and then upgrade
> $packages.  I wanted to decouple the build from install as I assumed that the
> delays in building libvirt (etc) would be problematic *and* provide another
> failure mode for devstack that we really don't want to deal with.
> 
> I was only thinking of having libvirt and qemu in there but if the plug-in was
> abstract enough it could easily provide packages for other help utils (like OVS
> and DPDK).
> 
> When I started looking at this Ubuntu was the likely candidate as Fedora in the gate
> wasn't really a stable thing.  I see a little more fedora in nodepool so perhaps a
> really quick win would be to just use the lib-virt preview on F22.

Trying to build from bleeding edge is just a can of worms as you'll need to
have someone baby-sitting the job to fix it up on new releases when the
list of build deps changes or build options alter. As an example, next
QEMU release will require you to pull in 3rd party libcacard library
for SPICE build, since it was split out, so there's already a build
change pending that would cause a regression in the gate.

So, my recommendation would really be to just use Fedora with virt-preview
for the bleeding edge and avoid trying to compile stuff in the gate. The
virt-preview repository tracks upstream releases of QEMU+Libvirt+libguestfs
with minimal delay and is built with the same configuration as future Fedora
releases will use. So such testing is good evidence that Nova won't break on
the next Fedora release.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|