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. Now some questions for the Infra folk: - What if any concerns do you have with a job on the experimental pipeline pulling stuff from the Internet? - Later if we wanted to add this job to the check pipeline would we need to mirror the repo closer to the nodes? Yours Tony.
pgpSCcQwujDwC.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