Open Stack

On Thu, Jan 23, 2014 at 5:21 AM, Steven Hardy <shardy at 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?

- 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?
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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140201/52af075f/attachment.html>