Open Stack

On Thu, Jul 17, 2014, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Wed, Jul 16, 2014 at 09:44:55AM -0700, Johannes Erdfelt wrote:
> > 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

It kind of helps. It's still implicit in that you need to look at what
features are enabled at what version and determine if it is being
tested.

But the behavior is still broken since code is still getting merged that
isn't tested. Saying that is by design doesn't help the fact that
potentially broken code exists.

Also, this explanation doesn't answer my question about what happens
when the gate finally gets around to actually testing those potentially
broken code paths.

JE