Open Stack

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