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

[Jamie Lennox]

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

> On Tue, Feb 23, 2016 at 8:49 PM, Jamie Lennox 
> wrote:
>
>>
>>
>> On 18 February 2016 at 10:50, Matt Fischer  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 

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

[Matt Fischer]

On Tue, Feb 23, 2016 at 8:49 PM, Jamie Lennox  wrote:

>
>
> On 18 February 2016 at 10:50, Matt Fischer  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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Jamie Lennox]

On 18 February 2016 at 10:50, Matt Fischer  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



> [3] "Making authentication request to
> http://127.0.0.1:5000/v3/v3/auth/tokens;
>
> __
> 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] [keystone] [horizon] [qa] keystone versionless endpoints and v3

[Matt Fischer]

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.

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?

Are services expected to handle versionless keystone endpoints properly?

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?

Do I need/Should I have both v2.0 and v3 endpoints in my catalog?


[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

[3] "Making authentication request to
http://127.0.0.1:5000/v3/v3/auth/tokens;
__
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