Open Stack

On 06/18/2015 11:17 AM, Chris Hoge wrote:
> 
>> On Jun 18, 2015, at 7:51 AM, Monty Taylor <mordred at inaugust.com> wrote:
>>
>> On 06/18/2015 10:48 AM, Rob Hirschfeld wrote:
>>> On 06/18/2015 07:43 AM, Monty Taylor wrote:
>>>> ... bit of a step from being reflective towards influencing what folks
>>>> _Should_ be doing. Agree - excellent topic fo mid-cycle. 
>>>
>>> From an interop perspective, it's part of our charter.  Some API
>>> differences are reasonable to absorb but we need to find a way to get
>>> ahead of the current sprawl and drive it back towards convergence.  The
>>> goal of DefCore was to create carrots and sticks.
>>>
>>
>> I'm honestly not sure I agree that some API differences are reasonable
>> to absorb - but I'm perfectly willing to accept it as a first step
>> position. :)
> 
> It’s unavoidable. If DefCore helps define a standard way to discover that
> interoperability, then its a good start, even if it means for a year OpenStack
> SDKs based on interoperability efforts needs a few nasty 'if-else’ blocks.
> 
> It will be necessary as preferred APIs transition. I think we made a mistake
> in admitting Glance v2 though. It seems like it will be ready for Liberty,
> but doesn’t seem ready now.

Agree.

> Keystone v2/v3 might also seem like another pain point, but there’s only
> one non-admin api call.

Keystone v3 is actually in MUCH better shape. Intra-openstack
consumption support for it is solid, and the keystoneauth middleware
that the keystone team put together supports the differences pretty
seamlessly. It's not a perfect transition, but it's totally managable
and one of the things I think we should start pushing people towards
(keystone v3 is SO MUCH BETTER of an api)

That said - I think this points out a good initial litmus test for us
considering new versions of APIs when the dev teams say they're ready.
Namely - do the other openstack services use the new API version yet?

Looking at those two - glance? no. nothing uses v2 yet. keystone? yes.
v3 support is everywhere.

> Networking? I don’t see a good solution for networking. Maybe defining
> the expected ways to accomplish a task like getting a public IP address?

Yeah. Networking is a mess, but I think we're all expecting it to
continue to be a mess until the nova-network/neutron stuff is finally
sorted.

> This part of why I want to work through the tests and map capabilities to
> APIs. Also, a more deliberate approach to defining capabilities. For example,
> 
> “tempest.api.compute.servers.test_create_server.ServersTestJSON.test_verify_created_server_vcpus”
> 
> exists as a test capability, but I don’t see anything like
> 
> “tempest.api.compute.servers.test_create_server.ServersTestJSON.test_create_server”.
> 
> (maybe "tempest.api.compute.servers.test_servers.ServersTestJSON.test_create_server_with_admin_password”?)
> 
> The former implies the latter, but it’s worrying that we just don’t have
> a direct test for the latter (unless I missed it somewhere). The test for a
> capability should give a developer a blueprint for answering the question
> “how do I do ‘x’?"

Yes. I can't even tell you how much time I spend trying to figure out
answers to "how do I do 'x'?"