Open Stack

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.

>  - instead implement a third party CI with the latest available
> libvirt release [1]

As for the general idea of doing CI, absolutely.  That was discussed
earlier in the thread, though nobody has picked up the ball yet.  I can
work on it, though.  We just need to figure out a sensible approach.

We've seen several times that building and maintaining 3rd party CI is a
*lot* of work.  Like you said in [1], doing this in infra's CI would be
ideal.  I think 3rd party should be reserved for when running it in the
project's infrastructure is not an option for some reason (requires
proprietary hw or sw, for example).

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'll mess around and see if I can spin up an experimental job.

>  - document clearly in the release notes the versions of dependancies
> that we tested against in a given release: hypervisor versions (gate
> and third party), etc etc

Sure, that sounds like a good thing to document in release notes.

-- 
Russell Bryant