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 <[email protected]> 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 _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
