Open Stack

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 <joe.gordon0 at gmail.com>
>On Tue, Jul 1, 2014 at 2:32 PM, Nels Nelson
><nels.nelson at rackspace.com> 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
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>