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

Sean Dague sean at dague.net
Thu May 4 10:58:20 UTC 2017

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

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 Dague

More information about the OpenStack-dev mailing list