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