Open Stack

On Tue, Jul 15, 2014 at 11:40 AM, Nels Nelson <nels.nelson at rackspace.com>
wrote:

> 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?
>
>
The hypervisor support status hinges on the existence of a third party
testing system (ci.openstack.org/third_party.html) that tests libvirt-lxc


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


You are using the category correctly, but you asked the questions in just
the right way that they didn't make a lot of sense (with tempest being
driver agnostic and all). As this is only a nova issue, you may have better
luck by bringing this topic up in the nova IRC room (
https://wiki.openstack.org/wiki/IRC#OpenStack_IRC_channels_.28chat.freenode.net.29
)



>
> 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
> >
> >
> >
>
> _______________________________________________
> 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/20140716/30636b84/attachment.html>