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 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
