Open Stack

On Wed, Jul 16, 2014 at 09:44:55AM -0700, Johannes Erdfelt wrote:
> On Wed, Jul 16, 2014, Mark McLoughlin <markmc at redhat.com> wrote:
> > No, there are features or code paths of the libvirt 1.2.5+ driver that
> > aren't as well tested as the "class A" designation implies. And we have
> > a proposal to make sure these aren't used by default:
> > 
> >   https://review.openstack.org/107119
> > 
> > i.e. to stray off the "class A" path, an operator has to opt into it by
> > changing a configuration option that explains they will be enabling code
> > paths which aren't yet tested upstream.
> 
> So that means the libvirt driver will be a mix of tested and untested
> features, but only the tested code paths will be enabled by default?
> 
> The gate not only tests code as it gets merged, it tests to make sure it
> doesn't get broken in the future by other changes.
> 
> What happens when it comes time to bump the default version_cap in the
> future? It looks like there could potentially be a scramble to fix code
> that has been merged but doesn't work now that it's being tested. Which
> potentially further slows down development since now unrelated code
> needs to be fixed.
> 
> This sounds like we're actively weakening the gate we currently have.

If the gate has libvirt 1.2.2 and a feature is added to Nova that
depends on libvirt 1.2.5, then the gate is already not testing that
codepath since it lacks the libvirt version neccessary to test it.
The version cap should not be changing that, it is just making it
more explicit that it hasn't been tested

Regards,
Daniel
-- 
|: 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 :|