Tony Breeds <t...@bakeyournoodle.com> wrote on 11/18/2015 10:43:30 PM:
> From: Tony Breeds <t...@bakeyournoodle.com> > To: "Daniel P. Berrange" <berra...@redhat.com>, "OpenStack Development > Mailing List (not for usage questions)" <openstack-dev@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) __________________________________________________________________________ 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