Open Stack

On 07/17/2014 11:40 AM, Daniel P. Berrange wrote:
> 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

And hopefully it will make future updates a little smoother.  We can
turn on the new features in only a subset of jobs to minimize potential
disruption.

-- 
Russell Bryant