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