Open Stack

On 23 June 2015 at 14:26, Mark Voelker <mvoelker at vmware.com> wrote:
> 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.

Just a few notes on these from e:

Well, we wish we had a console that works across all hypervisors, we
don't yet require console access. Its likely to be the console log
option that would become cross hypervisor, although its not yet
working and only uni-directional, the service console is the next best
best for cross hypervisor and bi-direction. But not of that really
helps anyone right now.

IMHO, we should focus on getting the external IP address of the VM
instead of trying to worry about console access. Using a "native"
method based on an "injected" asymmetric key, making use of the
external IP, seems a much better approach. Making horizon have the
available APIs to connect to the 'preferred' graphical console might
be a nice added extra.

Also, the Compute-volume is a proxy API. While we have not plans to
delete it (yet), people should really use the Cinder API instead. That
was the plan when we extracted the Cinder project from inside the Nova
project.

"test create project network" are also proxy APIs, its also really
outside of what should be used with nova-network.

Hope that is useful info.

Thanks,
John

> 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
>
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee