Names can make writing generic orchestration templates that would go in the 
applications catalog easier. Humans are much better at inputting a name rather 
then a uuid. You can even default a name in the text box and if they don't 
change any of the defaults, it will just work. You can't do that with a UUID 
since it is different on every cloud.

Thanks,
Kevin
________________________________
From: Jay Lau [jay.lau....@gmail.com]
Sent: Tuesday, June 02, 2015 12:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a 
required option when creating a Bay/Baymodel

Thanks Adrian, imho making name as required can bring more convenient to end 
users because UUID is difficult to use. Without name, the end user need to 
retrieve the UUID of the bay/baymodel first before he did some operations for 
the bay/baymodel, its really time consuming. We can discuss more in this week's 
IRC meeting. Thanks.


2015-06-02 14:08 GMT+08:00 Adrian Otto 
<adrian.o...@rackspace.com<mailto:adrian.o...@rackspace.com>>:
-1. I disagree.

I am not convinced that requiring names is a good idea. I've asked several 
times why there is a desire to require names, and I'm not seeing any persuasive 
arguments that are not already addressed by UUIDs. We have UUID values to allow 
for acting upon an individual resource. Names are there as a convenience. 
Requiring names, especially unique names, would make Magnum harder to use for 
API users driving Magnum from other systems. I want to keep the friction as low 
as possible.

I'm fine with replacing "None" with an empty string.

Consistency with Nova would be a valid argument if we were being more 
restrictive, but that's not the case. We are more permissive. You can use 
Magnum in the same way you use Nova if you want, by adding names to all 
resources. I don't see the wisdom in forcing that style of use without a 
technical reason for it.

Thanks,

Adrian

On May 31, 2015, at 4:43 PM, Jay Lau 
<jay.lau....@gmail.com<mailto:jay.lau....@gmail.com>> wrote:


Just want to use ML to trigger more discussion here. There are now bugs/patches 
tracing this, but seems more discussions are needed before we come to a 
conclusion.

https://bugs.launchpad.net/magnum/+bug/1453732
https://review.openstack.org/#/c/181839/
https://review.openstack.org/#/c/181837/
https://review.openstack.org/#/c/181847/
https://review.openstack.org/#/c/181843/

IMHO, making the Bay/Baymodel name as a MUST will bring more flexibility to end 
user as Magnum also support operating Bay/Baymodel via names and the name might 
be more meaningful to end users.

Perhaps we can borrow some iead from nova, the concept in magnum can be mapped 
to nova as following:

1) instance => bay
2) flavor => baymodel

So I think that a solution might be as following:
1) Make name as a MUST for both bay/baymodel
2) Update magnum client to use following style for bay-create and 
baymodel-create: DO NOT add "--name" option

root@devstack007:/tmp# nova boot
usage: nova boot [--flavor <flavor>] [--image <image>]
                 [--image-with <key=value>] [--boot-volume <volume_id>]
                 [--snapshot <snapshot_id>] [--min-count <number>]
                 [--max-count <number>] [--meta <key=value>]
                 [--file <dst-path=src-path>] [--key-name <key-name>]
                 [--user-data <user-data>]
                 [--availability-zone <availability-zone>]
                 [--security-groups <security-groups>]
                 [--block-device-mapping <dev-name=mapping>]
                 [--block-device key1=value1[,key2=value2...]]
                 [--swap <swap_size>]
                 [--ephemeral size=<size>[,format=<format>]]
                 [--hint <key=value>]
                 [--nic 
<net-id=net-uuid,v4-fixed-ip=ip-addr,v6-fixed-ip=ip-addr,port-id=port-uuid>]
                 [--config-drive <value>] [--poll]
                 <name>
error: too few arguments
Try 'nova help boot' for more information.
root@devstack007:/tmp# nova flavor-create
usage: nova flavor-create [--ephemeral <ephemeral>] [--swap <swap>]
                          [--rxtx-factor <factor>] [--is-public <is-public>]
                          <name> <id> <ram> <disk> <vcpus>

Please show your comments if any.

--
Thanks,

Jay Lau (Guangya Liu)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Thanks,

Jay Lau (Guangya Liu)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to