Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Monty Taylor]

On 05/04/2017 06:58 AM, Sean Dague wrote:

On 05/03/2017 11:56 PM, Monty Taylor wrote:

On 05/03/2017 03:47 AM, Thierry Carrez wrote:

Monty Taylor wrote:

On 05/01/2017 10:44 AM, Ben Swartzlander wrote:

On 04/28/2017 06:26 PM, Monty Taylor wrote:

[...]
Thoughts? Anyone violently opposed?


I don't have any problems with this idea. My main concern would be for
backwards-compatibility and it sounds like that's pretty well sorted
out.

I do think it's important that if we make this improvement that all the
projects really do get it done at around the same time, because if we
only implement it 80% of projects, it will look pretty weird.


I could not possibly agree more strongly with both points.


"All the projects [should] really [...] get it done at around the same
time, because if we only implement it 80% of projects, it will look
pretty weird" sounds pretty much like the definition of a good
cross-community goal. Can we afford to wait for Queens to implement this
? If yes it feels like this would make a great goal.



We could - and I agree with you ... but there is actually not work that
needs to be done in all of the projects. To support this from the
openstack side - we mostly need to land a patch to keystoneauth. (patch
already written) I will go check the other clientlibs, but I'm pretty
sure everyone has been updated to use keystoneauth at this point- except
swiftclient, but there is a patch up already to handle that. (also, nova
is working on consuming services via the catalog, but that patch is also
in flight and that work already has a local version of this done)

We also want to add support both for consuming this and testing it in
tempest - but that probably wants a deeper conversation with the tempest
team about the right way to do it.

In any case - I think the hardest part is ensuring consensus that it's a
good path forward, and a few logisitical concerns Sean and Morgan
brought up over in the service-types-authority and keystoneauth repos.
Once we find agreement, I can basically have this implemented on the
consume side in OpenStack in a few days.


On the aliases front... I'm actually a little concerned about putting
that into keystoneauth1 at all unless it's easy to globally disable,
because it glosses over the transition in a way that people may make
changes that assume differences in the service catalog than actually are
true.

There was an equivalent change when keystoneauth1 put in the magic that
allows OS_AUTH_URL to not have a version in it (which only works with
keystoneauth1 based clients). That meant that people started being told
that the keystone endpoint didn't need a version marker in the url.
Except, that kind of config would actually not work with every other
client out there. I actually wanted to revert that special work around,
but was told that basically lots of code now depends on it, so it would
break the world. :(


Totally. This is why a large part of this plan involves both 
documentation and not _only_ putting it in keystoneauth, but everywhere 
else too.


The thing is - the world is already broken because we have special 
snowflake workarounds in various of our python libs (python-cinderclient 
has a volume/volumev2/volumev3 workaround btw) We're also embracing 
microversions ... except that consuming microversions is impossible as 
an API consumer right now because it's unpossible to to get the 
discovery document as an API consumer. Well, unless you use 
python-novaclient which does magic URL inference to find the unversioned 
doc so nobody notices that a normal user has no access to the otherwise 
quite excellent mechanism.


This is why the summary of the plan is "define what things should look 
like in an area that is currently undefined, work to ensure backwards 
compatible consumption support for all of the consumers, encourage 
deployment adoption"



So I feel like we probably could use a powow in Boston to figure out the
concerns here. Because, honestly we can get compatibility without
keystoneauth1 by going wide here, and just asking folks to add all the
new entries (and making some validation system for people's service
catalog so they can see any changes that might be suggested).


Sure. We could only document and then ask all of the operators of all of 
the clouds out there to add new entries to the catalog. But they all 
won't - which means that client consumers _still_ won't be able to 
express "I want to connect to block-storage" and know that it'll just be 
a thing they can do.


I agree about a pow wow in Boston. We don't have to go with my proposed 
plan - I'll happily work to implement alternate plans as well ... but 
I'm very against continuing to spin our wheels in this area and continue 
to leave the problem to our API consumers with no help or guidance.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Sean Dague]

On 05/03/2017 11:56 PM, Monty Taylor wrote:
> On 05/03/2017 03:47 AM, Thierry Carrez wrote:
>> Monty Taylor wrote:
>>> On 05/01/2017 10:44 AM, Ben Swartzlander wrote:
 On 04/28/2017 06:26 PM, Monty Taylor wrote:
> [...]
> Thoughts? Anyone violently opposed?

 I don't have any problems with this idea. My main concern would be for
 backwards-compatibility and it sounds like that's pretty well sorted
 out.

 I do think it's important that if we make this improvement that all the
 projects really do get it done at around the same time, because if we
 only implement it 80% of projects, it will look pretty weird.
>>>
>>> I could not possibly agree more strongly with both points.
>>
>> "All the projects [should] really [...] get it done at around the same
>> time, because if we only implement it 80% of projects, it will look
>> pretty weird" sounds pretty much like the definition of a good
>> cross-community goal. Can we afford to wait for Queens to implement this
>> ? If yes it feels like this would make a great goal.
>>
> 
> We could - and I agree with you ... but there is actually not work that
> needs to be done in all of the projects. To support this from the
> openstack side - we mostly need to land a patch to keystoneauth. (patch
> already written) I will go check the other clientlibs, but I'm pretty
> sure everyone has been updated to use keystoneauth at this point- except
> swiftclient, but there is a patch up already to handle that. (also, nova
> is working on consuming services via the catalog, but that patch is also
> in flight and that work already has a local version of this done)
> 
> We also want to add support both for consuming this and testing it in
> tempest - but that probably wants a deeper conversation with the tempest
> team about the right way to do it.
> 
> In any case - I think the hardest part is ensuring consensus that it's a
> good path forward, and a few logisitical concerns Sean and Morgan
> brought up over in the service-types-authority and keystoneauth repos.
> Once we find agreement, I can basically have this implemented on the
> consume side in OpenStack in a few days.

On the aliases front... I'm actually a little concerned about putting
that into keystoneauth1 at all unless it's easy to globally disable,
because it glosses over the transition in a way that people may make
changes that assume differences in the service catalog than actually are
true.

There was an equivalent change when keystoneauth1 put in the magic that
allows OS_AUTH_URL to not have a version in it (which only works with
keystoneauth1 based clients). That meant that people started being told
that the keystone endpoint didn't need a version marker in the url.
Except, that kind of config would actually not work with every other
client out there. I actually wanted to revert that special work around,
but was told that basically lots of code now depends on it, so it would
break the world. :(

So I feel like we probably could use a powow in Boston to figure out the
concerns here. Because, honestly we can get compatibility without
keystoneauth1 by going wide here, and just asking folks to add all the
new entries (and making some validation system for people's service
catalog so they can see any changes that might be suggested).

-Sean

-- 
Sean Dague
http://dague.net

__
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

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Thierry Carrez]

Monty Taylor wrote:
> On 05/03/2017 03:47 AM, Thierry Carrez wrote:
>> Monty Taylor wrote:
>>> On 05/01/2017 10:44 AM, Ben Swartzlander wrote:
 On 04/28/2017 06:26 PM, Monty Taylor wrote:
> [...]
> Thoughts? Anyone violently opposed?

 I don't have any problems with this idea. My main concern would be for
 backwards-compatibility and it sounds like that's pretty well sorted
 out.

 I do think it's important that if we make this improvement that all the
 projects really do get it done at around the same time, because if we
 only implement it 80% of projects, it will look pretty weird.
>>>
>>> I could not possibly agree more strongly with both points.
>>
>> "All the projects [should] really [...] get it done at around the same
>> time, because if we only implement it 80% of projects, it will look
>> pretty weird" sounds pretty much like the definition of a good
>> cross-community goal. Can we afford to wait for Queens to implement this
>> ? If yes it feels like this would make a great goal.
>>
> 
> We could - and I agree with you ... but there is actually not work that
> needs to be done in all of the projects. To support this from the
> openstack side - we mostly need to land a patch to keystoneauth. (patch
> already written) I will go check the other clientlibs, but I'm pretty
> sure everyone has been updated to use keystoneauth at this point- except
> swiftclient, but there is a patch up already to handle that. (also, nova
> is working on consuming services via the catalog, but that patch is also
> in flight and that work already has a local version of this done)
> 
> We also want to add support both for consuming this and testing it in
> tempest - but that probably wants a deeper conversation with the tempest
> team about the right way to do it.
> 
> In any case - I think the hardest part is ensuring consensus that it's a
> good path forward, and a few logisitical concerns Sean and Morgan
> brought up over in the service-types-authority and keystoneauth repos.
> Once we find agreement, I can basically have this implemented on the
> consume side in OpenStack in a few days.
> 
> That's a super long response - sorry - I ramble. I'd be more than happy
> to make it a cross-project goal if we think that's the right way to get
> it done - but I worry that if we do it'll steal a valuable slot since
> there's not much of an ask from the projects on this one.

If it can be easily achieved, yes, just run for it !

-- 
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Monty Taylor]

On 05/03/2017 03:47 AM, Thierry Carrez wrote:

Monty Taylor wrote:

On 05/01/2017 10:44 AM, Ben Swartzlander wrote:

On 04/28/2017 06:26 PM, Monty Taylor wrote:

[...]
Thoughts? Anyone violently opposed?


I don't have any problems with this idea. My main concern would be for
backwards-compatibility and it sounds like that's pretty well sorted out.

I do think it's important that if we make this improvement that all the
projects really do get it done at around the same time, because if we
only implement it 80% of projects, it will look pretty weird.


I could not possibly agree more strongly with both points.


"All the projects [should] really [...] get it done at around the same
time, because if we only implement it 80% of projects, it will look
pretty weird" sounds pretty much like the definition of a good
cross-community goal. Can we afford to wait for Queens to implement this
? If yes it feels like this would make a great goal.



We could - and I agree with you ... but there is actually not work that 
needs to be done in all of the projects. To support this from the 
openstack side - we mostly need to land a patch to keystoneauth. (patch 
already written) I will go check the other clientlibs, but I'm pretty 
sure everyone has been updated to use keystoneauth at this point- except 
swiftclient, but there is a patch up already to handle that. (also, nova 
is working on consuming services via the catalog, but that patch is also 
in flight and that work already has a local version of this done)


We also want to add support both for consuming this and testing it in 
tempest - but that probably wants a deeper conversation with the tempest 
team about the right way to do it.


In any case - I think the hardest part is ensuring consensus that it's a 
good path forward, and a few logisitical concerns Sean and Morgan 
brought up over in the service-types-authority and keystoneauth repos. 
Once we find agreement, I can basically have this implemented on the 
consume side in OpenStack in a few days.


That's a super long response - sorry - I ramble. I'd be more than happy 
to make it a cross-project goal if we think that's the right way to get 
it done - but I worry that if we do it'll steal a valuable slot since 
there's not much of an ask from the projects on this one.


__
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

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Thierry Carrez]

Monty Taylor wrote:
> On 05/01/2017 10:44 AM, Ben Swartzlander wrote:
>> On 04/28/2017 06:26 PM, Monty Taylor wrote:
>>> [...]
>>> Thoughts? Anyone violently opposed?
>>
>> I don't have any problems with this idea. My main concern would be for
>> backwards-compatibility and it sounds like that's pretty well sorted out.
>>
>> I do think it's important that if we make this improvement that all the
>> projects really do get it done at around the same time, because if we
>> only implement it 80% of projects, it will look pretty weird.
> 
> I could not possibly agree more strongly with both points.

"All the projects [should] really [...] get it done at around the same
time, because if we only implement it 80% of projects, it will look
pretty weird" sounds pretty much like the definition of a good
cross-community goal. Can we afford to wait for Queens to implement this
? If yes it feels like this would make a great goal.

-- 
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Monty Taylor]

On 05/01/2017 10:44 AM, Ben Swartzlander wrote:

On 04/28/2017 06: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?


I don't have any problems with this idea. My main concern would be for
backwards-compatibility and it sounds like that's pretty well sorted out.

I do think it's important that if we make this improvement that all the
projects really do get it done at around the same time, because if we
only implement it 80% of projects, it will look pretty weird.


I could not possibly agree more strongly with both points.

__
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

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Ben Swartzlander]

On 04/28/2017 06: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?


I don't have any problems with this idea. My main concern would be for 
backwards-compatibility and it sounds like that's pretty well sorted out.


I do think it's important that if we make this improvement that all the 
projects really do get it done at around the same time, because if we 
only implement it 80% of projects, it will look pretty weird.



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

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Flavio Percoco]

On 29/04/17 22:40 -0500, Sean McGinnis wrote:

On Fri, Apr 28, 2017 at 05:26:16PM -0500, Monty Taylor wrote:

Hey everybody!

...

== Proposed Solution ==

... Clean things up
... Make things simple
... Don't break everybody



+1 from me. I think this is a good direction to go.



/me likes!
/me likes very much!

+1

--
@flaper87
Flavio Percoco


signature.asc
Description: PGP signature
__
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

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Davanum Srinivas]

+1 from me as well Monty

On Sat, Apr 29, 2017 at 11:40 PM, Sean McGinnis  wrote:
> On Fri, Apr 28, 2017 at 05:26:16PM -0500, Monty Taylor wrote:
>> Hey everybody!
>>
>> ...
>>
>> == Proposed Solution ==
>>
>> ... Clean things up
>> ... Make things simple
>> ... Don't break everybody
>>
>
> +1 from me. I think this is a good direction to go.
>
> Sean
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Sean McGinnis]

On Fri, Apr 28, 2017 at 05:26:16PM -0500, Monty Taylor wrote:
> Hey everybody!
> 
> ...
>
> == Proposed Solution ==
>
> ... Clean things up
> ... Make things simple
> ... Don't break everybody
>

+1 from me. I think this is a good direction to go.

Sean

__
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

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Renat Akhmerov]

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 , 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  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
> > 

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Monty Taylor]

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  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 

Re: [openstack-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Eric Fried]

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: 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-dev] [all][tc][cinder][mistral][manila] A path forward to shiny consistent service types

[Monty Taylor]

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