Open Stack

On Sat, Feb 1, 2014 at 12:33 PM, Anne Gentle <anne at openstack.org> wrote:

>
>
>
> 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?
>

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