Open Stack

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 <mordred at 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
> > version​less 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 <mordred at 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-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
> >
>
>
> __________________________________________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170429/e0c0dbae/attachment.html>