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.
pgpRTXZ7Y2HFP.pgp
Description: PGP signature
__________________________________________________________________________ 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