Open Stack

Tony Breeds <tony at bakeyournoodle.com> wrote on 11/18/2015 10:43:30 PM:

> From: Tony Breeds <tony at bakeyournoodle.com>
> To: "Daniel P. Berrange" <berrange at redhat.com>, "OpenStack Development
> Mailing List (not for usage questions)" 
<openstack-dev at lists.openstack.org>
> Date: 11/18/2015 10:44 PM
> Subject: Re: [openstack-dev] [nova][infra] Getting a bleeding edge 
> libvirt gate job running
> 
> On Wed, Nov 18, 2015 at 11:46:40AM +0000, Daniel P. Berrange wrote:
> > 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.
> 
> Right, that's why I wanted to decouple the build from the gate. releases 
don't
> happen that often so if virt-preview/UCA isn't appropraite for some 
reason I
> can easly dedicate a day/project/release to build the packages.
> 
> > 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.
> 
> Right that was more or less my motivation.
> 
> Yours Tony.

Sometimes I get lost in threads, so I try to summarize the current 
progress here:

Interim summary
===============
* Building libvirt from source is a bad idea
* Other functionality has also the need to test latest greates (OVS)
* Using a Fedora with enabled "virt-preview" would be already available
* The Ubuntu cloud archives (UCA) do not have the latest libvirt

TBC:
----
* @ubuntu: Is there a change to have a UCA with latest libvirt? (tonyb)
* @infra: What if any concerns do you have with a job on the 
  experimental pipeline pulling stuff from the Internet? (tonyb)
* @infra: Later if we wanted to add this job to the check pipeline would
  we need to mirror the repo closer to the nodes? (tonyb)

Regards, Markus Zoeller (markus_z)