Open Stack

Thanks Adrian, some questions and comments in-line.

2015-06-03 10:29 GMT+08:00 Adrian Otto <adrian.otto at rackspace.com>:

>  I have reflected on this further and offer this suggestion:
>
>  1) Add a feature to Magnum to auto-generate human readable names, like
> Docker does for un-named containers, and ElasticSearch does for naming
> cluster nodes. Use this feature if no name is specified upon the creation
> of a Bay or Baymodel.
>
+1 on this

>
>  -and-
>
>  2) Add a configuration directives (default=FALSE) for
> allow_duplicate_bay_name and allow_duplicate_baymodel_name. If TRUE,
> duplicate named Bay and BayModel resources will be allowed, as they are
> today.
>
>  This way, by default Magnum requires a unique name, and if none is
> specified, it will automatically generate a name. This way no additional
> burden is put on users who want to act on containers exclusively using
> UUIDs, and cloud operators can decide if they want to enforce name
> uniqueness or not.
>
>  In the case of clouds that want to allow sharing access to a BayModel
> between multiple tenants (example: a global BayModel named “kubernetes”)
> with allow_duplicate_baymodel_name set to FALSE, a user will still be
> allowed to
>
Here should be allow_duplicate_baymodel set to TRUE?

> create a BayModel with the name “kubernetes” and it will override the
> global one. If a user-supplied BayModel is present with the same name as a
> global one, we shall automatically select the one owned by the tenant.
>
+1 on this , one question is what does a "global BayModel" means? In
Magnum, all BayModel belong to a tenant and seems there is no global
BayModel?

>
>  About Sharing of BayModel Resources:
>
>  Similarly, if we add features to allow one tenant to share a BayModel
> with another tenant (pending acceptance of the offered share), and
> duplicate names are allowed, then prefer in this order: 1) Use the resource
> owned by the same tenant, 2) Use the resource shared by the other tenant
> (post acceptance only), 3) Use the global resource. If duplicates exist in
> the same scope of ownership, then raise an exception requiring the use of a
> UUID in that case to resolve the ambiguity.
>
We can file a bp to trace this.

>
>  One expected drawback of this approach is that tools designed to
> integrate with one Magnum may not work the same with another Magnum if the
> allow_duplicate_bay* settings are changed from the default values on one
> but not the other. This should be made clear in the comments above the
> configuration directive in the example config file.
>
Just curious why do we need this feature? Different Magnum clusters might
using different CoE engine. So you are mentioning the case all of the
Magnum clusters are using same  CoE engine? If so, yes, this should be made
clear in configuration file.

 Adrian
>
>   On Jun 2, 2015, at 8:44 PM, Jay Lau <jay.lau.513 at gmail.com> wrote:
>
>   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://OpenStack-dev-request@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://OpenStack-dev-request@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
>
>
>
> __________________________________________________________________________
> 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/20150604/c3449e1a/attachment-0001.html>