Thanks for your response, Joe. Am I understanding you correctly that the Hypervisor Support Status does not in fact hinge on any particular Tempest tests, but rather, simply on individual tests for the libvirt-lxc driver used for gating?
Also, one last question, am I using the incorrect [subheader][category] info in my subject? I've had to bump this topic twice now, and you're the only person to reply. Thanks very much for your time. Best regards, -Nels Nelson From: Joe Gordon <[email protected]> >On Tue, Jul 1, 2014 at 2:32 PM, Nels Nelson ><[email protected]> wrote: > >Greetings list,- > >Over the next few weeks I will be working on developing additional Tempest >gating unit and functional tests for the libvirt-lxc compute driver. > > > >Tempest is driver agnostic, just like the nova APIs strive to be. As a >consumer of nova I shouldn't need to know what driver is being used. >So there should not be any libvirt-lxc only tests in Tempest. > > > >I am trying to figure out exactly what is required in order to accomplish >the goal of ensuring the continued inclusion (without deprecation) of the >libvirt-lxc compute driver in OpenStack. My understanding is that this >requires the upgrading of the support status in the Hypervisor Support >Matrix document by developing the necessary Tempest tests. To that end, I >am trying to determine what tests are necessary as precisely as possible. > >I have some questions: > >* Who maintains the Hypervisor Support Matrix document? > > >https://wiki.openstack.org/wiki/HypervisorSupportMatrix ><https://wiki.openstack.org/wiki/HypervisorSupportMatrix> > >* Who is in charge of the governance over the Support Status process? Is >there single person in charge of evaluating every driver? > > > > >The nova team is responsible for this, with the PTL as the lead of that >team. > > > > * Regarding that process, how is the information in the Hypervisor >Support Matrix substantiated? Is there further documentation in the wiki >for this? Is an evaluation task simply performed on the functionality for >the given driver, and the results logged in the HSM? Is this an automated >process? Who is responsible for that evaluation? > > > >I am actually not sure about this one, but I don't believe it is >automated though. > > > > * How many of the boxes in the HSM must be checked positively, in >order to move the driver into a higher supported group? (From group C to >B, and from B to A.) > > * Or, must they simply all be marked with a check or minus, >substantiated by a particular gating test which passes based on the >expected support? > > * In other words, is it sufficient to provide enough automated testing >to simply be able to indicate supported/not supported on the support >matrix chart? Else, is writing supporting documentation of an evaluation >of the hypervisor sufficient to substantiate those marks in the support >matrix? > > * Do "unit tests that gate commits" specifically refer to tests >written to verify the functionality described by the annotation in the >support matrix? Or are the annotations substantiated by "functional >testing that gate commits"? > > > >In order to get a driver out of group C and into group B, a third party >testing system should run tempest on all nova patches. Similar to what we >have for Xen >(https://review.openstack.org/#/q/reviewer:openstack%2540citrix.com+status >:open,n,z). > >To move from Group B to group A, the driver must have first party testing >that we gate on (we cannot land any patches that fail for that driver). > > > >Thank you for your time and attention. > >Best regards, >-Nels Nelson >Software Developer >Rackspace Hosting > > > >_______________________________________________ >OpenStack-dev mailing list >[email protected] >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
