<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;">This looks like a simple and elegant way to solve the issue. 100% supported by me (and hopefully others).
<div><br /></div>
<div>Thanks for addressing it.</div>
</div>
<div name="messageSignatureSection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><br />
Renat</div>
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><br />
On 29 Apr 2017, 06:19 +0700, Monty Taylor <mordred@inaugust.com>, wrote:<br />
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;">On 04/28/2017 06:07 PM, Adrian Turjak wrote:<br />
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;"><br />
This sounds like a fantastic path forward as the version in the service<br />
type is a source of frustration in some ways. I personally love the<br />
versionless discoverability of Keystone as an API model.<br /></blockquote>
<br />
++ ... I'll follow up on Monday with an email about consumption of<br />
version discovery.<br />
<br />
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;">I'm also assuming this is related to this repo here:<br />
https://github.com/openstack/service-types-authority<br />
<br />
Are there plans to actually fill that repo out and start building the<br />
full 'official' catalog of service types? Because right now that repo is<br />
missing many services but appears to actually be a good place to list<br />
what all the various service types are already in use.<br /></blockquote>
<br />
Yes, absolutely. If we can get this particular party moving I'd like to<br />
use that as a little motivation to chug through and get that repo<br />
completed. (It's not super hard - but without an answer to what to do<br />
about the old names, the conversations stall out a bit)<br />
<br />
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;">I know that trying to choose a good new service type for a project is<br />
hard because finding a list for the ones already in use isn't that easy.<br />
I was sad to find that repo, although ideal, was lacking.<br /></blockquote>
<br />
++ totally agree.<br />
<br />
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;"><br />
On 29 Apr. 2017 10:26 am, Monty Taylor <mordred@inaugust.com> wrote:<br />
<br />
Hey everybody!<br />
<br />
Yay! (I'm sure you're all saying this, given the topic. I'll let you<br />
collect yourself from your exuberant celebration)<br />
<br />
== Background ==<br />
<br />
As I'm sure you all know, we've been trying to make some hearway for a<br />
while on getting service-types that are registered in the keystone<br />
service catalog to be consistent. The reason for this is so that API<br />
Consumers can know how to request a service from the catalog. That<br />
might<br />
sound like a really easy task - but uh-hoh, you'd be so so wrong. :)<br />
<br />
The problem is that we have some services that went down the path of<br />
suggesting people register a new service in the catalog with a version<br />
appended. This pattern was actually started by nova for the v3 api but<br />
which we walked back from - with "computev3". The pattern was picked up<br />
by at least cinder (volumev2, volumev3) and mistral (workflowv2) that I<br />
am aware of. We're also suggesting in the service-types-authority that<br />
manila go by "shared-file-system" instead of "share".<br />
<br />
(Incidentally, this is related to a much larger topic of version<br />
discovery, which I will not bore you with in this email, but about<br />
which<br />
I have a giant pile of words just waiting for you in a little bit. Get<br />
excited about that!)<br />
<br />
== Proposed Solution ==<br />
<br />
As a follow up to the consuming version discovery spec, which you<br />
should<br />
absolutely run away from and never read, I wrote these:<br />
<br />
https://review.openstack.org/#/c/460654/ (Consuming historical aliases)<br />
and<br />
https://review.openstack.org/#/c/460539/ (Listing historical aliases)<br />
<br />
It's not a particularly clever proposal - but it breaks down like this:<br />
<br />
* Make a list of the known historical aliases we're aware of - in a<br />
place that isn't just in one of our python libraries (460539)<br />
* Write down a process for using them as part of finding a service from<br />
the catalog so that there is a clear method that can be implemented by<br />
anyone doing libraries or REST interactions. (460654)<br />
* Get agreement on that process as the "recommended" way to look up<br />
services by service-type in the catalog.<br />
* Implement it in the base libraries OpenStack ships.<br />
* Contact the authors of as many OpenStack API libraries that we can<br />
find.<br />
* Add tempest tests to verify the mappings in both directions.<br />
* Change things in devstack/deployer guides.<br />
<br />
The process as described is backwards compatible. That is, once<br />
implemented it means that a user can request "volumev2" or<br />
"block-storage" with version=2 - and both will return the endpoint the<br />
user expects. It also means that we're NOT asking existing clouds to<br />
run<br />
out and break their users. New cloud deployments can do the new thing -<br />
but the old values are handled in both directions.<br />
<br />
There is a hole, which is that people who are not using the base libs<br />
OpenStack ships may find themselves with a new cloud that has a<br />
different service-type in the catalog than they have used before. It's<br />
not idea, to be sure. BUT - hopefully active outreach to the community<br />
libraries coupled with documentation will keep the issues to a minimum.<br />
<br />
If we can agree on the matching and fallback model, I am<br />
volunteering to<br />
do the work to implement in every client library in which it needs<br />
to be<br />
implemented across OpenStack and to add the tempest tests. (it's<br />
actually mostly a patch to keystoneauth, so that's actually not _that_<br />
impressive of a volunteer) I will also reach out to as many of the<br />
OpenStack API client library authors as I can find, point them at the<br />
docs and suggest they add the support.<br />
<br />
Thoughts? Anyone violently opposed?<br />
<br />
Thanks for reading...<br />
<br />
Monty<br />
<br />
__________________________________________________________________________<br />
OpenStack Development Mailing List (not for usage questions)<br />
Unsubscribe:<br />
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br />
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br />
<br />
<br />
<br />
<br />
__________________________________________________________________________<br />
OpenStack Development Mailing List (not for usage questions)<br />
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br />
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br />
<br /></blockquote>
<br />
<br />
__________________________________________________________________________<br />
OpenStack Development Mailing List (not for usage questions)<br />
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br />
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br /></blockquote>
</div>
</body>
</html>