Open Stack

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.