I logged this here: https://blueprints.launchpad.net/keystone/+spec/endpoint-template-types
I don't know when we'll get to it, though. Essex is booked and right now the focus is on stabilizing. This is also an API change, so it might be fitting for a v3.0 of the API whenever we decide to move to that. Feels like Essex+1 to me. Is there a piece of this or a blocker we need to address today? From: Marcelo Martins <[email protected]<mailto:[email protected]>> Date: Tue, 1 Nov 2011 10:16:34 -0500 To: Ziad Sawalha <[email protected]<mailto:[email protected]>> Cc: Joseph Heck <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Openstack] keystone Endpoint schema Aww I see, that would be cool Marcelo Martins Openstack-swift [email protected]<mailto:[email protected]> “Knowledge is the wings on which our aspirations take flight and soar. When it comes to surfing and life if you know what to do you can do it. If you desire anything become educated about it and succeed. “ On Nov 1, 2011, at 9:05 AM, Ziad Sawalha wrote: We also need to consider the use case where a role may have rights over multiple services. Cloud Admin for example. EndpointType would allow us to do this: endpointTemplate add [region] [service] [type=public|internal|admin…other] [url] [enabled] [is_global] That would allow services to register as many endpoints and endpoint types as they needed. Z From: Marcelo Martins <[email protected]<mailto:[email protected]>> Date: Mon, 31 Oct 2011 19:26:12 -0500 To: Ziad Sawalha <[email protected]<mailto:[email protected]>> Cc: Joseph Heck <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [Openstack] keystone Endpoint schema Hi Ziad, Sorry, that was my mistake. I meant to have "case service.name:" on that pseudocode and not type. I wasn't proposing any EndpointType and don't see how that would help. The way that I was thinking was, you can either have the "services" table pre-populated during keystone install/setup or have the user do it. Also provide information on the docs about the services that keystone currently support. The documentation would provide information to the user on how to add an endpointTemplate to a particular service. Perhaps this is a bit more clear: case service.name<http://service.name/>: openstack-swift) try endpointTemplate add [region] [service] [public_url] [internal_url] [enabled] [is_global] except "Failed with improper number of arguments"swift) show_some_help() try openstack-compute) endpointTemplate add [region] [service] [public_url] [admin_url] [internal_url] [enabled] [is_global] .... openstack-swift) If one needs to add a "generic/custom" service (one that keystone does not know yet), perhaps keystone could be flexible enough to accept N numbers of URLs for this "generic/custom" service. But I think this is something more for the future. Marcelo Martins Openstack-swift [email protected]<mailto:[email protected]> “Knowledge is the wings on which our aspirations take flight and soar. When it comes to surfing and life if you know what to do you can do it. If you desire anything become educated about it and succeed. “ On Oct 31, 2011, at 4:42 PM, Ziad Sawalha wrote: The list of URLs comes from what we have historically done at Rackspace and the conversations had in OpenStack about a management/admin API. I agree that not all services need those three. And some may want to create additional ones. You mention "type" below. Not to be confused with the serviceType (like compute, identity, image-service, object-store, etc...). Are you proposing an EndpointType (maybe admin, public, private, etc..)? That does seem like a more flexible approach. It would help to have some well-known types, such as: - public: Internet-accessible - admin: private, with elevated-privilege calls available - internal: provides a high bandwidth, low latency, unmetered endpoint Thoughts? Z On Oct 31, 2011, at 2:17 PM, "Marcelo Martins" <[email protected]<mailto:[email protected]>> wrote: It should require/accept the number of URLs that is required by the type of service one is adding. For example, swift only has public and localnet storage URLs. No admin URL. So, regardless if one is using keystone-manage or not (not sure what else one can use, Rest calls maybe ? ), it should only accept what the service type requires. case type: swift) try endpointTemplate add [region] [service] [public_url] [internal_url] [enabled] [is_global] except "Failed with improper number of arguments" show_some_help() nova) .... keystone) ... another-service) .... whatever_else) ... Marcelo Martins Openstack-swift [email protected]<mailto:[email protected]> “Knowledge is the wings on which our aspirations take flight and soar. When it comes to surfing and life if you know what to do you can do it. If you desire anything become educated about it and succeed. “ On Oct 31, 2011, at 1:52 PM, Joseph Heck wrote: Can you provide an example? I think you're asserting that you'd like the keystone-manage command to not require 3 different URLs when they don't exist separately, is that correct? -joe On Oct 31, 2011, at 11:45 AM, Marcelo Martins wrote: Well, If you need to specify a "type" when adding an endpointTemplate, then keystone should be smart enough to identify the type given and only accept the number of URLs needed for such type of service. Marcelo Martins Openstack-swift [email protected]<mailto:[email protected]> On Oct 31, 2011, at 1:40 PM, Joseph Heck wrote: That's just what it sees today - the only one of the service endpoints that uses all three (right now anyway) is Keystone itself. Can you share a different pattern that you're interested in seeing supported? -joe On Oct 31, 2011, at 9:46 AM, Marcelo Martins wrote: What makes keystone assume that all types of services will have " [public_url] [admin_url] [internal_url] "? Marcelo Martins Openstack-swift [email protected]<mailto:[email protected]> _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected]<mailto:[email protected]> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
