[openstack-dev] [keystone] [horizon] [qa] keystone versionless endpoints and v3

Jamie Lennox jamielennox at gmail.com
Wed Mar 9 00:09:48 UTC 2016


So with the merge of [1] the devstack change [2] to use unversioned
endpoints passes gate. From previous experience this should not be
considered an extensive test, however the only real way to find out what
doesn't work is to merge it and see what fails.


[1] https://review.openstack.org/#/c/287532/
[2] https://review.openstack.org/#/c/285879/

On 9 March 2016 at 10:21, Matt Fischer <matt at mattfischer.com> wrote:

> On Tue, Feb 23, 2016 at 8:49 PM, Jamie Lennox <jamielennox at gmail.com>
> wrote:
>
>>
>>
>> On 18 February 2016 at 10:50, Matt Fischer <matt at mattfischer.com> wrote:
>>
>>> I've been having some issues with keystone v3 and versionless endpoints
>>> and I'd like to know what's expected to work exactly in Liberty and beyond.
>>> I thought with v3 we used versionless endpoints but it seems to cause some
>>> breakages and some disagreement as to what should work.
>>>
>>
>> Excellent! I'm really glad someone is looking into this beyond the simple
>> cases.
>>
>>
>>> Here's what I've found:
>>>
>>> Using versionless endpoints:
>>>  - horizon project selector doesn't work (v3 api configured in horizon
>>> local_settings) [1]
>>>  - keystone client doesn't work (expected v3 I think)
>>>  - nova/neutron etc seem ok with a few exceptions [2]
>>>
>>> Adding /v3 to my endpoints:
>>>  - openstackclient seems to double up the /v3 reference which fails [3],
>>> this breaks puppet-openstack, in addition to general CLI usage.
>>>
>>> Adding /v2.0 to my endpoints:
>>>  - things seem to work the best this way
>>>  - this matches the install docs too
>>>  - its not very "v3-onic"
>>>
>>>
>>> My goal is to be as v3 as possible, but everything needs to work 100%.
>>> Given that...
>>>
>>> What's the correct and supported way to setup endpoints such that
>>> Keystone v3 works?
>>>
>>
>> So the problem with switching to v3 is that a lot of services and clients
>> were designed to assume you would have a /v2.0 on your URL. To work with v3
>> they therefore inspect the url and essentially s/v2.0/v3 before making
>> calls. Any of the services using the keystoneclient/keystoneauth session
>> stuff correctly shouldn't have this problem - but that is certainly not
>> everyone.
>>
>> It does however explain why you see problems with /v3 where /v2.0 seems
>> to work even for the v3 API.
>>
>>
>>> Are services expected to handle versionless keystone endpoints properly?
>>>
>>
>> Services should never need to manipulate the catalog. This is what's
>> causing the problem. If they leave it up to the client to do this then it
>> will handle the unversioned endpoint.
>>
>>
>>>
>>>
>> Can I ignore that keystoneclient doesn't work with versionless? Does this
>>> imply that services that use the python library (like Horizon) will also be
>>> broken?
>>>
>>
>> This I'm surprised by. Do you mean the keystone CLI utility that ships
>> with keystoneclient? If so the decision was made it should never support v3
>> and to use openstackclient instead. I haven't actually looked at this in a
>> long time but we should probably fix it even though it's been deprecated
>> for a long time now.
>>
>>
>>> Do I need/Should I have both v2.0 and v3 endpoints in my catalog?
>>>
>>> No. And particularly with the new catalog formats that went through the
>> cross project working group recently we made the decision that these
>> endpoints should not contain a version number at all. This is not ready yet
>> but we are working towards that goal.
>>
>>
>>> [1] its making curl calls without a version on the endpoint, causing it
>>> to fail. I will file a bug pending the outcome of this discussion.
>>>
>>> [2] specifically neutron_admin_auth_url in nova.conf doesn't seem to
>>> work without a Keystone API version on it. For
>>> cinder keymgr_encryption_auth_url also seems to need it. I assume I'll
>>> eventually also hit some of these:
>>> https://etherpad.openstack.org/p/v3-only-devstack
>>>
>>
>> Can you file bugs for both of these? I've worked on both these sections
>> before so should be able to have a look into it.
>>
>> I was going to finish by saying that we have unversioned endpoints in
>> devstack - but looking again now and we don't :( There have been various
>> reverted patches in the v3 transition and this must have been one of them.
>>
>> For now i would suggest keeping the endpoints with the /v2.0 prefix as
>> even things using v3 API know how to work around this. The goal is to go
>> versionless everywhere (including other services, long goal but the others
>> will be easier than keystone) and anything you find that isn't working
>> isn't using the clients correctly so file a bug and add me to it.
>>
>>
>> Jamie
>>
>
> Jamie,
>
> Apologies for the delay in response and thanks for the information.  I had
> come to the same conclusion as you after sending this, leaving /v2.0 on the
> URLs in the catalog but specifying v3 seems to work the best for now in
> Liberty. I look forward to the day when v3+versionless is the default!
>
> I will bring my test env back up later this week and work on bugs for both
> issues that I called out.
>
> __________________________________________________________________________
> 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/20160309/82e0c6ee/attachment.html>


More information about the OpenStack-dev mailing list