Open Stack

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
btorch-os at 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 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
>> btorch-os at zeroaccess.org
> 
>> 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
>>>> btorch-os at zeroaccess.org
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20111031/82cb20df/attachment.html>