Open Stack

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160308/ed911ba2/attachment.html>