Open Stack

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.Fox at 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.513 at 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.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)
>
> __________________________________________________________________________
> 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/20150603/0f81f295/attachment.html>