Open Stack

----- Original Message -----
> From: "Ben Meyer" <ben.meyer at rackspace.com>
> To: openstack-dev at lists.openstack.org
> Sent: Monday, October 20, 2014 3:53:39 PM
> Subject: Re: [openstack-dev] [Keystone] Question regarding Service Catalog and	Identity entries...
> 
> 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.

It's required for the CRUD operations (managing users, projects, roles etc) of keystoneclient. Whether it's realistic that you would ever separate the auth process to a different host than the keystone CRUD I'm not sure, i've never seen it, but the idea is that beyond that initial auth contact there really is no difference between keystone and any other service and keystoneclient will look up the catalog to determine how to talk to keystone. 

> > 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".

As keystoneclient is used by heat, horizon etc I would think it's safe to say it's required. 

> Thanks
> 
> Ben
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>