Open Stack

I agree on referencing objects by name rather than just by id. This can be
definitely done before F-3, and if the name is not unique, then we can
return an error message asking the user to specify the id, with the list of
possible ids returned by the command. Then the goal for grizzly would be
tab completion, I hope.

I also had the impression Yong felt we should change the approach that
we've adopted for the show command as well, so maybe he can provide more
information.

Salvatore

On 27 July 2012 21:21, Dan Wendlandt <dan at nicira.com> wrote:

> I think its really nice to be able to reference a network by name (rather
> than just by UUID) when specifying the network in a port-create or
> subnet-create command.  Otherwise you're basically focusing a cut-and-paste
> for anyone using the CLI (and forcing awk parsing for anyone using
> scripting).
>
> My understanding is that Salvatore's patch added support for using names
> in 'show' commands only, but the same logic should probably be used for
> update + delete commands, as well as for arguments to create commands.
>
> To be honest, I'm not quite sure whether there's agreement or not on the
> above thread, so clarifying points we still need to discuss would be useful
> for me.
>
> Dan
>
>
> On Fri, Jul 27, 2012 at 12:29 AM, Salvatore Orlando <sorlando at nicira.com>wrote:
>
>> Hi Yong,
>>
>> I am not sure if you're referring to the change that has been merged, or
>> to the use of names in command that reference to other resources (such as
>> port-create with requires a net id).
>>
>> In the former case, if you believe the merged change does something
>> unacceptable, please file a bug so that we can either revert it or replace
>> with something better.
>>
>> In the latter case, as stated in my previous email I think that using
>> name as a reference might improve usability even if we have to be careful
>> about non-uniqueness.
>>
>> Salvatore
>>
>>
>> On 27 July 2012 09:23, Yong Sheng Gong <gongysh at cn.ibm.com> wrote:
>>
>>> Hi,
>>> I found https://review.openstack.org/#/c/10276/ is just for quantum
>>> x-show command and where it uses xx_list as the result of show if the
>>> argument is a name.
>>> This is binding xx-list and xx-show command.
>>> I think when we cannot get the resource with the name_or_id, we should:
>>> 1. use the name_or_id as a name to get the right id
>>> 2. and then use the id to do the related operation: such as show,
>>> delete, and update.
>>>
>>> Regards,
>>> Yong Sheng Gong
>>>
>>> -----Yong Sheng Gong/China/IBM at IBMCN wrote: -----
>>> To: dan at nicira.com, "Salvatore Orlando" <sorlando at nicira.com><sorlando at nicira.com>,
>>> gkotton at redhat.com
>>> From: Yong Sheng Gong/China/IBM at IBMCN
>>> Date: 07/27/2012 02:57PM
>>> Cc: OpenStack Development Mailing List
>>> <openstack-dev at lists.openstack.org> <openstack-dev at lists.openstack.org>
>>> Subject: [openstack-dev] [quantum] about use name as command cli's
>>> argument
>>>
>>>
>>>
>>> Hi,
>>> I want to talk about the name_or_id argument in quantum client commands.
>>> For example:
>>> 1. quantum net-create myname
>>> 2. quantum net-show myname or id
>>> 3. quantum subnet-create network_id 10.0.1.0/24 --name mysub
>>> here subnet-create cannot use networkname.
>>> 4.quanum subnet-show mysub
>>>
>>> All in all, If we want to show, delete and update a resource, we can use
>>> name or id to specify the resource. When using name,  the number of that
>>> resource with the given name must be 1.
>>> When we reference a resource in another resource, for example, we create
>>> a subnet under a network, we must reference that network by id.
>>>
>>> So, are these implementations acceptable?
>>>
>>> Thanks
>>> Yong Sheng Gong
>>>  _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120727/a26977c1/attachment.html>