On Fri, Aug 08, 2014 at 09:06:29AM -0400, Russell Bryant wrote:
> On 08/07/2014 08:06 PM, Michael Still wrote:
> > It seems to me that the tension here is that there are groups who
> > would really like to use features in newer libvirts that we don't CI
> > on in the gate. Is it naive to think that a possible solution here is
> > to do the following:
> > 
> >  - revert the libvirt version_cap flag
> I don't feel strongly either way on this.  It seemed useful at the time
> for being able to decouple upgrading libvirt and enabling features that
> come with that.  I'd like to let Dan get back from vacation and weigh in
> on it, though.

Yes, I think that version cap feature is valuable no matter what we
do about CI testing, which is why I +2'd it originally.

> I wonder if the job could be as simple as one with an added step in the
> config to install latest libvirt from source.  Dan, do you think someone
> could add a libvirt-current.tar.gz to http://libvirt.org/sources/ ?
> Using the latest release seems better than master from git.

I'd strongly recommend against using GIT master. It will cause openstack
CI more pain than benefits. Using the latest stable release is a better

> I'll mess around and see if I can spin up an experimental job.

There is work to add support for this in devestack already which I
prefer since it makes it easy for developers to get an environment
which matches the build system:


|: 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-dev mailing list

Reply via email to