Open Stack

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
>
> * 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140715/01c1e1fd/attachment.html>