Open Stack

On 07/17/2014 02:31 PM, Johannes Erdfelt wrote:
> 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.

Well, it may not be tested in our CI yet, but that doesn't mean it's not
tested some other way, at least.

I think there are some good ideas in other parts of this thread to look
at how we can more reguarly rev libvirt in the gate to mitigate this.

There's also been work going on to get Fedora enabled in the gate, which
is a distro that regularly carries a much more recent version of libvirt
(among other things), so that's another angle that may help.

> 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.

I think we would just test out the bump and make sure it's working fine
before it's enabled for every job.  That would keep potential breakage
localized to people working on debugging/fixing it until it's ready to go.

-- 
Russell Bryant