Open Stack

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.otto at 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.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?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,

Jay Lau (Guangya Liu)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150602/00f72d99/attachment.html>