Open Stack

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.

> However, not everything is tested now, nor is the tests we have
> foolproof. When you consider the number of configuration options we
> have, the supported distros, the ranges of library versions we claim to
> support, etc., etc. I don't think we can ever get to an "everything is
> tested" point.
> 
> In the absence of that, I think we should aim to be more clear what *is*
> tested. The config option I suggest does that, which is a big part of
> its merit IMHO.

I like the sound of this especially since it's not clear right now at
all.

JE