[openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

Steven Dake (stdake) stdake at cisco.com
Tue Jun 2 14:22:25 UTC 2015


I can see both points of view.  Principle of least surprise applies here.  A list of bays without names would be surprising for a tenant imo :)  I don’t particularly have a strong opinion, but my inclination is to lean towards non-unique names as a requirement for creating bays.

Again I am not strongly opinionated on this point so I’ll roll with whatever hits the code base ;-)

Regards
-steve

From: Adrian Otto <adrian.otto at rackspace.com<mailto:adrian.otto at rackspace.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Monday, June 1, 2015 at 11:08 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel

-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.513 at gmail.com<mailto:jay.lau.513 at 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 at 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 at 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-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150602/853f58ac/attachment.html>


More information about the OpenStack-dev mailing list