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