[openstack-dev] [keystone][heat] Migration to keystone v3 API questions

Adam Young ayoung at redhat.com
Tue Jan 28 20:45:57 UTC 2014


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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




More information about the OpenStack-dev mailing list