Re: [Openstack] keystone Endpoint schema

2011-11-01 Thread Ziad Sawalha
...@mac.com, openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net 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

Re: [Openstack] keystone Endpoint schema

2011-11-01 Thread Marcelo Martins
@lists.launchpad.net openstack@lists.launchpad.net 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

Re: [Openstack] keystone Endpoint schema

2011-11-01 Thread Ziad Sawalha
: Joseph Heck he...@mac.commailto:he...@mac.com, openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] keystone Endpoint schema Aww I see, that would be cool Marcelo Martins Openstack-swift btorch

[Openstack] keystone Endpoint schema

2011-10-31 Thread Marcelo Martins
What makes keystone assume that all types of services will have [public_url] [admin_url] [internal_url] ? Marcelo Martins Openstack-swift btorch...@zeroaccess.org “Knowledge is the wings on which our aspirations take flight and soar. When it comes to surfing and life if you know what to

Re: [Openstack] keystone Endpoint schema

2011-10-31 Thread Marcelo Martins
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 btorch...@zeroaccess.org “Knowledge is the wings on

Re: [Openstack] keystone Endpoint schema

2011-10-31 Thread Joseph Heck
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

Re: [Openstack] keystone Endpoint schema

2011-10-31 Thread Marcelo Martins
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

Re: [Openstack] keystone Endpoint schema

2011-10-31 Thread Joseph Heck
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

Re: [Openstack] keystone Endpoint schema

2011-10-31 Thread Ziad Sawalha
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

Re: [Openstack] keystone Endpoint schema

2011-10-31 Thread Marcelo Martins
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