Open Stack

On 10/20/2014 08:12 AM, Jamie Lennox wrote:
> ----- Original Message -----
>> From: "Ben Meyer" <ben.meyer at rackspace.com>
>> To: openstack-dev at lists.openstack.org
>> Cc: "Jamie Painter" <jamie.painter at rackspace.com>
>> Sent: Tuesday, October 7, 2014 4:31:16 PM
>> Subject: [openstack-dev] [Keystone] Question regarding Service Catalog and	Identity entries...
>>
>> I am trying to use the Python Keystone client to integration
>> authentication functionality into a project I am contributing to
>> (https://github.com/rackerlabs/deuce-client).
>> However, I ran into a situation where if I do the following:
>>
>>>>> c = keystoneclient.v2_0.client.Client(username='username',
>> password='password',
>> auth_url="https://keystone-compatible-service.example.com/v2.0/")
>> Failed to retrieve management_url from token
>>
>> I traced it through the Python Keystoneclient code and it fails due to
>> not finding the "identity" service entry in the Service Catalog. The
>> authentication otherwise happens in that it has already received a
>> "successful" response and a full Service Catalog, aside from the
>> "missing" identity service. This happens with both version 0.10 and 0.11
>> python keystone clients; I did not try older clients.
>>
>> Talking with the service provider, their version does not include itself
>> in the Service Catalog, and they learned the Keystone itself inserts
>> itself into the Service Catalog.
>> I can certainly understand why it having the identity service entry be
>> part of the Service Catalog, but for them it is (at least for now) not
>> desirable to do so.
>>
>> Questions:
>> - Is it now a standard that Keystone inserts itself into the Service
>> Catalog?
> It's not a standard that keystone inserts itself into the catalog, the cloud operator should maintain the list of endpoints for their deployment and the 'identity' service should be amongst those endpoints. I'm unclear as to why it would be undesirable to list the identity endpoint in the service catalog. How would this addition change their deployment? 
The argument is that the Service Catalog is too big so they are hesitant
to add new entries to it; and 'identity' in the catalog is redundant
since you have to know the 'identity' end-point to even get the service
catalog in the first place.

Not saying I agree, just that's the argument being made. If it is
"required by Keystone" to be self-referential then they are likely to
add it.

> The problem with the code that you provided is that the token that is being returned from your code is unscoped. Which means that it is not associated with a project and therefore it doesn't have a service catalog because the catalog can be project specific. Thus when you go to perform an operation the client will look for the URL it is supposed to talk to in an empty list and fail to find the identity endpoint. This message really needs to be improved. If you add a project_id or project_name to the client information then you should get back a token with a catalog. 

In my normal case I'm using the project_id field; but have found that it
didn't really matter what was used for the credentials in this case
since they simply don't have the 'identity' end-points in the Service
Catalog.

>> - Or is the Python Keystone Client broken because it is forcing it to be so?
> I wouldn't say that it is broken because having an identity endpoint in your catalog is a required part of a deployment, in the same way that having a 'compute' endpoint is required if you want to talk to nova. I would be surprised by any decision to purposefully omit the 'identity' endpoint from the service catalog. 

See above; but from what you are presenting here it sounds like the
deployment is "broken" so it is in fact "required by Keystone", even if
only "a required part of a deployment".

Thanks

Ben