Open Stack

----- Original Message -----
> From: "Steven Hardy" <shardy at redhat.com>
> To: openstack-dev at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>