Re: [openstack-dev] [keystone][heat] Migration to keystone v3 API questions
On Sat, Feb 1, 2014 at 12:33 PM, Anne Gentle a...@openstack.org wrote:
On Thu, Jan 23, 2014 at 5:21 AM, Steven Hardy sha...@redhat.com wrote:
Hi all,
I've recently been working on migrating the heat internal interfaces to
use
the keystone v3 API exclusively[1].
This work has mostly been going well, but I've hit a couple of issues
which
I wanted to discuss, so we agree the most appropriate workarounds:
1. keystoneclient v3 functionality not accessible when catalog contains a
v2 endppoint:
In my test environment my keystone endpoint looks like:
http://127.0.0.1:5000/v2.0
And I'd guess this is similar to the majority of real deployments atm?
Yes, I was just researching this for the Ops Guide O'Reilly edition, and
don't see evidence of deployments doing otherwise in their endpoint
definition.
Also I didn't uncover many (any?) deployments going from Identity v2 to v3
yet. Meaning, if they're already running v2, when they upgrade to havana,
they do not move to Identity v3.
So when creating a keystoneclient object I've been doing:
from keystoneclient.v3 import client as kc_v3
v3_endpoint = self.context.auth_url.replace('v2.0', 'v3')
client = kc_v3.Client(auth_url=v3_endpoint, ...
Which, assuming the keystone service has both v2 and v3 API's enabled
works, but any attempt to use v3 functionality fails with 404 because
keystoneclient falls back to using the v2.0 endpoint from the catalog.
So to work around this I do this:
client = kc_v3.Client(auth_url=v3_endpoint, endpoint=v3_endpoint, ...
client.authenticate()
Which results in the v3 features working OK.
So my questions are:
- Is this a reasonable workaround for production environments?
- What is the roadmap for moving keystone endpoints to be version
agnostic?
- Is there work ongoing to make the client smarter in terms of figuring
out
what URL to use (version negotiation or substituting the appropriate
path
when we are in an environment with a legacy v2.0 endpoint..)
I'd like to understand the ramifications of
https://review.openstack.org/#/c/62801/ so I have a few questions:
- If keystone service catalog endpoints become version agnostic, does that
make other project's support of multiple versions of the Identity API
easier?
Yes, because they can discover the versioned API endpoint they need at
runtime (which may differ from that required by another identity client),
rather than requiring additional external configuration (or adding further
bloat to the service catalog; every service that's overloading the service
type with versioning is doing it *terribly* wrong).
- If the client gets smarter, does that automatically let Heat support
Identity v2? Or is more work required in Heat after your blueprint at [1]
is complete?
I saw a brief discussion at project meeting Jan 14 [3] but I didn't see
any questioning of whether it's premature to preclude the use of Identity
v2 in any integrated project.
Can we discuss implications and considerations at the project meeting next
week?
Sure!
Thanks,
Anne
[3]
http://eavesdrop.openstack.org/meetings/project/2014/project.2014-01-14-21.02.log.html
2. Client (CLI) support for v3 API
What is the status re porting keystoneclient to provide access to the v3
functionality on the CLI?
In particular, Heat is moving towards using domains to encapsulate the
in-instance users it creates[2], so administrators will require some way
to
manage users in a non-default domain, e.g to get visibility of what Heat
is
doing in that domain and debug in the event of any issues.
If anyone can provide any BP links or insight that would be much
appreciated!
Thanks,
Steve
[1] https://blueprints.launchpad.net/heat/+spec/keystone-v3-only
[2] https://wiki.openstack.org/wiki/Heat/Blueprints/InstanceUsers
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][heat] Migration to keystone v3 API questions
On 01/23/2014 06:21 AM, Steven Hardy wrote:
Hi all,
I've recently been working on migrating the heat internal interfaces to use
the keystone v3 API exclusively[1].
This work has mostly been going well, but I've hit a couple of issues which
I wanted to discuss, so we agree the most appropriate workarounds:
1. keystoneclient v3 functionality not accessible when catalog contains a
v2 endppoint:
Please chime in here:
https://review.openstack.org/#/c/62801/
In my test environment my keystone endpoint looks like:
http://127.0.0.1:5000/v2.0
And I'd guess this is similar to the majority of real deployments atm?
So when creating a keystoneclient object I've been doing:
from keystoneclient.v3 import client as kc_v3
v3_endpoint = self.context.auth_url.replace('v2.0', 'v3')
client = kc_v3.Client(auth_url=v3_endpoint, ...
Which, assuming the keystone service has both v2 and v3 API's enabled
works, but any attempt to use v3 functionality fails with 404 because
keystoneclient falls back to using the v2.0 endpoint from the catalog.
So to work around this I do this:
client = kc_v3.Client(auth_url=v3_endpoint, endpoint=v3_endpoint, ...
client.authenticate()
Which results in the v3 features working OK.
So my questions are:
- Is this a reasonable workaround for production environments?
- What is the roadmap for moving keystone endpoints to be version agnostic?
- Is there work ongoing to make the client smarter in terms of figuring out
what URL to use (version negotiation or substituting the appropriate path
when we are in an environment with a legacy v2.0 endpoint..)
2. Client (CLI) support for v3 API
What is the status re porting keystoneclient to provide access to the v3
functionality on the CLI?
In particular, Heat is moving towards using domains to encapsulate the
in-instance users it creates[2], so administrators will require some way to
manage users in a non-default domain, e.g to get visibility of what Heat is
doing in that domain and debug in the event of any issues.
If anyone can provide any BP links or insight that would be much
appreciated!
Thanks,
Steve
[1] https://blueprints.launchpad.net/heat/+spec/keystone-v3-only
[2] https://wiki.openstack.org/wiki/Heat/Blueprints/InstanceUsers
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone][heat] Migration to keystone v3 API questions
- Original Message -
From: Steven Hardy sha...@redhat.com
To: openstack-dev@lists.openstack.org
Sent: Thursday, 23 January, 2014 9:21:47 PM
Subject: [openstack-dev] [keystone][heat] Migration to keystone v3 API
questions
Hi all,
I've recently been working on migrating the heat internal interfaces to use
the keystone v3 API exclusively[1].
This work has mostly been going well, but I've hit a couple of issues which
I wanted to discuss, so we agree the most appropriate workarounds:
1. keystoneclient v3 functionality not accessible when catalog contains a
v2 endppoint:
In my test environment my keystone endpoint looks like:
http://127.0.0.1:5000/v2.0
And I'd guess this is similar to the majority of real deployments atm?
So when creating a keystoneclient object I've been doing:
from keystoneclient.v3 import client as kc_v3
v3_endpoint = self.context.auth_url.replace('v2.0', 'v3')
client = kc_v3.Client(auth_url=v3_endpoint, ...
Which, assuming the keystone service has both v2 and v3 API's enabled
works, but any attempt to use v3 functionality fails with 404 because
keystoneclient falls back to using the v2.0 endpoint from the catalog.
So to work around this I do this:
client = kc_v3.Client(auth_url=v3_endpoint, endpoint=v3_endpoint, ...
client.authenticate()
Which results in the v3 features working OK.
So my questions are:
- Is this a reasonable workaround for production environments?
- What is the roadmap for moving keystone endpoints to be version agnostic?
- Is there work ongoing to make the client smarter in terms of figuring out
what URL to use (version negotiation or substituting the appropriate path
when we are in an environment with a legacy v2.0 endpoint..)
This is a known issue and something that has come up for discussion many times
and
we don't have a great solution for it. This problem won't be unique to keystone
it
is a side effect of having versioned endpoints in the service catalog.
We are slowly attempting to transition the entire service catalog over to
unversioned endpoints. There is a lot of problems though regarding this and
maintaining comptability with existing clients and installations. There are some
hacks we are discussing that will hopefully allow us to transition keystone and
the other clients over - this is but one advantage of getting a more common
client
going.
To more directly answer the question, there is slow work ongoing in this area
but
for the time being the best advice i have is to set
client.management_url = v3_endpoint and it will override the service
catalog for the lifetime of the client (endpoint= should work but your above
example
will involve to authentication requests).
If you have any ideas on how to handle this transition and provide backwards
compat
I'd love to hear them.
2. Client (CLI) support for v3 API
What is the status re porting keystoneclient to provide access to the v3
functionality on the CLI?
In particular, Heat is moving towards using domains to encapsulate the
in-instance users it creates[2], so administrators will require some way to
manage users in a non-default domain, e.g to get visibility of what Heat is
doing in that domain and debug in the event of any issues.
If anyone can provide any BP links or insight that would be much
appreciated!
There is general consensus here that we will not be providing CLI access to
the V3 API via the keystoneclient package. This responsibility has been
dumped on^H^H^H taken over by the common openstack client. I am not aware of
when OSC will be considered production ready.
Sorry i couldn't bring more positive news,
Jamie
Thanks,
Steve
[1] https://blueprints.launchpad.net/heat/+spec/keystone-v3-only
[2] https://wiki.openstack.org/wiki/Heat/Blueprints/InstanceUsers
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [keystone][heat] Migration to keystone v3 API questions
Hi all,
I've recently been working on migrating the heat internal interfaces to use
the keystone v3 API exclusively[1].
This work has mostly been going well, but I've hit a couple of issues which
I wanted to discuss, so we agree the most appropriate workarounds:
1. keystoneclient v3 functionality not accessible when catalog contains a
v2 endppoint:
In my test environment my keystone endpoint looks like:
http://127.0.0.1:5000/v2.0
And I'd guess this is similar to the majority of real deployments atm?
So when creating a keystoneclient object I've been doing:
from keystoneclient.v3 import client as kc_v3
v3_endpoint = self.context.auth_url.replace('v2.0', 'v3')
client = kc_v3.Client(auth_url=v3_endpoint, ...
Which, assuming the keystone service has both v2 and v3 API's enabled
works, but any attempt to use v3 functionality fails with 404 because
keystoneclient falls back to using the v2.0 endpoint from the catalog.
So to work around this I do this:
client = kc_v3.Client(auth_url=v3_endpoint, endpoint=v3_endpoint, ...
client.authenticate()
Which results in the v3 features working OK.
So my questions are:
- Is this a reasonable workaround for production environments?
- What is the roadmap for moving keystone endpoints to be version agnostic?
- Is there work ongoing to make the client smarter in terms of figuring out
what URL to use (version negotiation or substituting the appropriate path
when we are in an environment with a legacy v2.0 endpoint..)
2. Client (CLI) support for v3 API
What is the status re porting keystoneclient to provide access to the v3
functionality on the CLI?
In particular, Heat is moving towards using domains to encapsulate the
in-instance users it creates[2], so administrators will require some way to
manage users in a non-default domain, e.g to get visibility of what Heat is
doing in that domain and debug in the event of any issues.
If anyone can provide any BP links or insight that would be much
appreciated!
Thanks,
Steve
[1] https://blueprints.launchpad.net/heat/+spec/keystone-v3-only
[2] https://wiki.openstack.org/wiki/Heat/Blueprints/InstanceUsers
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
