Re: [openstack-dev] [Keystone] Question regarding Service Catalog and Identity entries...
- Original Message - From: Ben Meyer ben.me...@rackspace.com To: openstack-dev@lists.openstack.org Sent: Monday, October 20, 2014 3:53:39 PM Subject: Re: [openstack-dev] [Keystone] Question regarding Service Catalog andIdentity entries... 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. 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo
Re: [openstack-dev] [Keystone] Question regarding Service Catalog and Identity entries...
- 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 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. - 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. Thanks, Benjamen R. Meyer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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.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
[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? - Or is the Python Keystone Client broken because it is forcing it to be so? Thanks, Benjamen R. Meyer ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
