I think that we did not come to a conclusion in today's IRC meeting. Adrian proposed that Magnum generate a unique name just like what docker is doing for "docker run", the problem mentioned by Andrew Melton is that Magnum support multi tenant, we should support the case that bay/baymodel under different tenant can have same name, the unique name is not required.
Also we may need support name update as well if the end user specify a name by mistake and want to update it after the bay/baymodel was created. Hmm.., looking forward to more comments from you. Thanks. 2015-06-02 23:34 GMT+08:00 Fox, Kevin M <kevin....@pnnl.gov>: > 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>: > >> -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> 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 >> ?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://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 > > -- 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
