On 10/20/2014 08:12 AM, Jamie Lennox wrote:
> ----- Original Message -----
>> From: "Ben Meyer" <ben.me...@rackspace.com>
>> To: openstack-dev@lists.openstack.org
>> Cc: "Jamie Painter" <jamie.pain...@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

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to