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 :| __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
