Open Stack

On 04/28/2017 05:45 PM, Eric Fried wrote:
> I love this.  Will it be done by July 20th [1] so I can use it in Pike
> for [2]?
>
> [1] https://wiki.openstack.org/wiki/Nova/Pike_Release_Schedule
> [2] https://review.openstack.org/#/c/458257/4/nova/utils.py@1508

There is absolutely nothing about the impl that should take even that 
long. That said - if we get consensus that the overall 
algorithm/approach is ok, then coding it directly in your patches and 
then removing that code when it's available in the next library down 
should be safe from a behavior perspective.

> On 04/28/2017 05:26 PM, Monty Taylor wrote:
>> Hey everybody!
>>
>> Yay! (I'm sure you're all saying this, given the topic. I'll let you
>> collect yourself from your exuberant celebration)
>>
>> == Background ==
>>
>> As I'm sure you all know, we've been trying to make some hearway for a
>> while on getting service-types that are registered in the keystone
>> service catalog to be consistent. The reason for this is so that API
>> Consumers can know how to request a service from the catalog. That might
>> sound like a really easy task - but uh-hoh, you'd be so so wrong. :)
>>
>> The problem is that we have some services that went down the path of
>> suggesting people register a new service in the catalog with a version
>> appended. This pattern was actually started by nova for the v3 api but
>> which we walked back from - with "computev3". The pattern was picked up
>> by at least cinder (volumev2, volumev3) and mistral (workflowv2) that I
>> am aware of. We're also suggesting in the service-types-authority that
>> manila go by "shared-file-system" instead of "share".
>>
>> (Incidentally, this is related to a much larger topic of version
>> discovery, which I will not bore you with in this email, but about which
>> I have a giant pile of words just waiting for you in a little bit. Get
>> excited about that!)
>>
>> == Proposed Solution ==
>>
>> As a follow up to the consuming version discovery spec, which you should
>> absolutely run away from and never read, I wrote these:
>>
>> https://review.openstack.org/#/c/460654/ (Consuming historical aliases)
>> and
>> https://review.openstack.org/#/c/460539/ (Listing historical aliases)
>>
>> It's not a particularly clever proposal - but it breaks down like this:
>>
>> * Make a list of the known historical aliases we're aware of - in a
>> place that isn't just in one of our python libraries (460539)
>> * Write down a process for using them as part of finding a service from
>> the catalog so that there is a clear method that can be implemented by
>> anyone doing libraries or REST interactions. (460654)
>> * Get agreement on that process as the "recommended" way to look up
>> services by service-type in the catalog.
>> * Implement it in the base libraries OpenStack ships.
>> * Contact the authors of as many OpenStack API libraries that we can find.
>> * Add tempest tests to verify the mappings in both directions.
>> * Change things in devstack/deployer guides.
>>
>> The process as described is backwards compatible. That is, once
>> implemented it means that a user can request "volumev2" or
>> "block-storage" with version=2 - and both will return the endpoint the
>> user expects. It also means that we're NOT asking existing clouds to run
>> out and break their users. New cloud deployments can do the new thing -
>> but the old values are handled in both directions.
>>
>> There is a hole, which is that people who are not using the base libs
>> OpenStack ships may find themselves with a new cloud that has a
>> different service-type in the catalog than they have used before. It's
>> not idea, to be sure. BUT - hopefully active outreach to the community
>> libraries coupled with documentation will keep the issues to a minimum.
>>
>> If we can agree on the matching and fallback model, I am volunteering to
>> do the work to implement in every client library in which it needs to be
>> implemented across OpenStack and to add the tempest tests. (it's
>> actually mostly a patch to keystoneauth, so that's actually not _that_
>> impressive of a volunteer) I will also reach out to as many of the
>> OpenStack API client library authors as I can find, point them at the
>> docs and suggest they add the support.
>>
>> Thoughts? Anyone violently opposed?
>>
>> Thanks for reading...
>>
>> Monty
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>