This looks like a simple and elegant way to solve the issue. 100% supported by me (and hopefully others).
Thanks for addressing it. Renat On 29 Apr 2017, 06:19 +0700, Monty Taylor <mord...@inaugust.com>, wrote: > On 04/28/2017 06:07 PM, Adrian Turjak wrote: > > > > This sounds like a fantastic path forward as the version in the service > > type is a source of frustration in some ways. I personally love the > > versionless discoverability of Keystone as an API model. > > ++ ... I'll follow up on Monday with an email about consumption of > version discovery. > > > I'm also assuming this is related to this repo here: > > https://github.com/openstack/service-types-authority > > > > Are there plans to actually fill that repo out and start building the > > full 'official' catalog of service types? Because right now that repo is > > missing many services but appears to actually be a good place to list > > what all the various service types are already in use. > > Yes, absolutely. If we can get this particular party moving I'd like to > use that as a little motivation to chug through and get that repo > completed. (It's not super hard - but without an answer to what to do > about the old names, the conversations stall out a bit) > > > I know that trying to choose a good new service type for a project is > > hard because finding a list for the ones already in use isn't that easy. > > I was sad to find that repo, although ideal, was lacking. > > ++ totally agree. > > > > > On 29 Apr. 2017 10:26 am, Monty Taylor <mord...@inaugust.com> 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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev