[OpenStack-DefCore] Expanding compute capabilities

Ievgeniia Zadorozhna izadorozhna at mirantis.com
Tue Jun 23 14:02:31 UTC 2015


Hi Mark,

Thanks for your detailed answer. Please, don't get me wrong, I'm not really
familiar with DefCore’s Core Criteria. So, I appreciated the provided
information and will analyze the propositions.

Actually, I don't suggest existing tests for defcore, I’m just asking what
useful our Mirantis team can do. I am not very experienced and don't have a
lot of information about the features spreaded on different public
OpenStack based clouds. Our suggestion is based only on our possibility of
expanding tempest tests for non-admin users. All other criteria are up to
Defcore team, so we ask you for some piece of advice. What tests from
proposed list will be preferable to see in defcore test list?

2015-06-23 16:26 GMT+03:00 Mark Voelker <mvoelker at vmware.com>:

> Hi Levgeniia,
>
> If you’re not already familiar with DefCore’s Core Criteria, I’d suggest
> having a look at:
>
> https://github.com/openstack/defcore/blob/master/process/CoreCriteria.rst
>
> That should give you a better picture of what capabilities would make good
> candidates for Core.  It might be useful for you to step through some items
> you think are candidates for Core and do a mock scoring of each one so you
> can see for yourself how they stack up against those criteria.  So, for
> example: you mention the spice console test.  I find that it’s often useful
> to do a quick “first pass” using the four criteria groups, and then drill
> into each group’s individual criteria if things look promising.  If we were
> to consider including this capability in Core, we’d ask if it:
>
> 1.)  Shows Proven Usage: probably not.  Specifically this would likely
> fall down on the “Widely Deployed” criteria.  You mentioned that you had
> questions about whether it was enabled in public clouds, and moreover it’s
> only supported on KVM (x86) and QEMU according to the Nova hypervisor
> support matrix [1], so it’s very unlikely to meet the bar here.
>
> 2.)  Aligns With Technical Direction: probably not.  While it’s something
> nova has supported for some time and will likely continue to support, the
> Nova community has made SPICE a “choice” of console implementation
> according to the hypervisor support matrix [1].  That is, Nova backends are
> required to support some form of console access and SPICE is merely one of
> those options (other implementations like a serial console are possible as
> well).  Thus, the technical community doesn’t seem to feel that SPICE
> support is important for all Nova implementations.
>
> 3.)  Plays Well With Others: Maybe.  It is documented.  There is a degree
> of discoverability in that you can at least specify in a POST request that
> you want a spice console, although it’s sort of a try-catch situation.  It
> wasn’t required in the past (but that’s ok; we have to introduce new
> capabilities sometime).
>
> 4.)  Takes A System View: probably not.  Other tests that are required are
> very unlikely to require a working SPICE console today, and similar
> functionality can be had from other console implementations.
>
> So based on that quick pass at scoring I would imagine that the get spice
> console test is probably not a good candidate for DefCore.  If some of
> these had looked promising I might take more time to evaluate individual
> criteria within those four groups, but in this case it seems pretty clear
> cut.  I would suggest that you do a quick pass on the other items you’ve
> listed here to see how they stack up—that may help prune your list a bit.
>
> [1]
> http://docs.openstack.org/developer/nova/support-matrix.html#console_spice
>
> At Your Service,
>
> Mark T. Voelker
>
> > On Jun 23, 2015, at 6:42 AM, Ievgeniia Zadorozhna <
> izadorozhna at mirantis.com> wrote:
> >
> > Hi,
> >
> > I am in progress of investigating the Compute API for expanding the
> coverage of api/compute tests for non-admin user and creating more tests.
> > After the investigation of Compute API and existing tests in tempest, as
> a result, we can add some tests to following capabilities:
> >
> > * compute-volume:
> >     * test list snapshots;
> >     * test list details for snapshots;
> >     * test create snapshot;
> >     * test delete snapshot;
> >     * test show snapshot.
> >
> > * compute-servers:
> >     * test get spice console (if it is enabled on public clouds).
> >
> > Also, since users can create networks in their own tenants, I want to
> propose to add in api/compute/test_tenant_networks.py the following tests
> that use “os-tenant-networks” compute extension in the API requests:
> >     * test create project network;
> >     * test delete project network.
> > The current status of api/compute/test_tenant_networks.py tests suite is
> that it has only 2 tests (list_tenant_networks, get_tenant_network), so if
> users can manipulate their networks we can expand the coverage by adding
> more actions with tenant networks.
> > These tests don't belong to any capability right now so maybe new
> capability should be created.
> >
> > Please share your thoughts about, which of these tests can be useful for
> defcore project?
> >
> > I'll continue looking for more non-admin compute API requests that are
> not covered in tempest yet. If you have any additional information or ideas
> please feel free to share.
> >
> >
> > --
> > Best regards,
> >
> > Ievgeniia Zadorozhna
> > QA Engineer
> > Mirantis Inc
> >
> >
> > Follow the OpenStack Silicon Valley event on Twitter
> > _______________________________________________
> > Defcore-committee mailing list
> > Defcore-committee at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee
>
>


-- 
Best regards,

Ievgeniia Zadorozhna
QA Engineer
Mirantis Inc

[image: OSSV-signature-2015.gif] <http://www.openstacksv.com/>
Follow the OpenStack Silicon Valley event on Twitter
<https://twitter.com/OpenStackSV>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20150623/490d0eaf/attachment.html>


More information about the Defcore-committee mailing list