Open Stack

On 06/29/2015 05:36 AM, John Garbutt wrote:
> On 26 June 2015 at 13:17, Monty Taylor <mordred at inaugust.com> wrote:
>> On 06/26/2015 08:04 AM, John Garbutt wrote:
>>> 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
>>
>> Yes. Getting the external IP address of the VM is one of the hardest
>> things in OpenStack. It's even worse than image uploads. :)
> 
> +1
> 
> Its also harder to fix, in some ways, but more important.
> 
>>> instead of trying to worry about console access. Using a "native"
>>> method based on an "injected" asymmetric key, making use of the
>>
>> It's possible that I'm misunderstanding here - but please don't require
>> 'injecting' anything into a guest VM to enable things. I use console
>> access to debug when something in the boot process has broken (it's the
>> only time it's a useful thing)
>>
>> If the VM is operational - then ssh or RDP should work fine and the
>> cloud does not need to help me. If it's NOT operational, then whatever
>> key or service was injected in the VM also likely isn't working, and
>> using things like out-of-band serial console as provided by the
>> hypervisor is the best thing we've got.
> 
> I think I am attempting to agree with you here.
> 
> console log and serial console are two different features right now
> (sigh), and neither are supported by all hypervisors right now. We
> sure need to sort that out.
> 
>>> 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.
>>
>> The most frequent thing I have to debug using the console is why can I
>> not connect to the external IP. his was especially true when I was
>> debugging the program we had to write to get images that were bootable
>> on both Rackspace and HP because of the wildly divergent networking
>> models in each of them. OOB console that depends on a VMs external IP
>> would be completely and utterly useless.
> 
> Agreed, I think.
> 
> I am more saying, we probably need the lowest common denominator, and
> the best thing. Not sure we agreed what "best" is right now, but it
> would be nice for there to be a concept of "preferred". I am failing
> to articulate this properly, I need to go get a coffee.

I mean ... get coffee, but I grok the words you are saying.

>> Although please, again - let's spend effort getting "get me the VM's
>> external IP" operational.
>>
>> Honestly, if we've got problem children hypervisors that cannot provide
>> an out of band console access that we can interact with - we should
>> likely be working with their creators to get one - or we should be
>> considering dropping them as backends.
> 
> I am wanting to do this as part of the Nova 'Feature Classification'
> effort I haven't had chance to kick off yet. These are super important
> parts of that conversation.
> 
>>> 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.
>>
>> ++
>>
>> (I vote for deleting it - Cinder has been around WELL long enough)
> 
> I think we agreed to talk about deleting things in Barcelona.
> Mostly so we don't get distracted by that conversation.

Ah - neat.  I look forward to that.

> The harder bits are the Nova create parameters that make Nova create
> volumes on the users behalf. But anyways, agreed we are getting close
> to the point when we could delete that, if we get the messaging
> "correct".

Amusingly enough - that's my current favorite part of the Nova API. :)
Like, if create could also do that with floating ips, it would be
spectacular... but now we're getting off topic.


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