Open Stack

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151119/5f9d35bf/attachment.pgp>