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

Jay Lau jay.lau.513 at gmail.com
Fri Jun 5 02:12:53 UTC 2015


I have filed a bp for this
https://blueprints.launchpad.net/magnum/+spec/auto-generate-name Thanks

2015-06-04 14:14 GMT+08:00 Jay Lau <jay.lau.513 at gmail.com>:

> Thanks Adrian, I see. Clear now.
>
> 2015-06-04 11:17 GMT+08:00 Adrian Otto <adrian.otto at rackspace.com>:
>
>>  Jay,
>>
>> On Jun 3, 2015, at 6:42 PM, Jay Lau <jay.lau.513 at gmail.com> wrote:
>>
>>   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?
>>
>>
>>  I know this is confusing, but yes, what I wrote was correct. Perhaps I
>> could rephrase it to clarify:
>>
>>  Regardless of the setting of allow_duplicate_bay* settings, we should
>> allow a user to create a BayModel with the same name as a global or shared
>> one in order to override the one that already exists from another source
>> with one supplied by the user. When referred to by name, the one created by
>> the user would be selected in the case where each has the same name
>> assigned.
>>
>>     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?
>>
>>
>>  This is a concept we have not actually discussed, and we don't have
>> today as a feature. The idea is that in addition to the BayModel resources
>> that tenants create, we could also have ones that the cloud operator
>> creates, and automatically expose to all tenants in the system. I am
>> referring to these as "global" BayModel resources as a potential future
>> enhancement.
>>
>>  The rationale for such a global resource is a way for the Cloud
>> Operator to pre-define the COE's they support, and pre-seed the Magnum
>> environment with such a configuration for all users. Implementing this
>> would require a solution for how to handle the ssh keypair, as one will
>> need to be generated uniquely for every tenant. Perhaps we could have a
>> procedure that a tenant uses to "activate" the BayModel by somehow adding
>> their own public ssh key to a local subclass of it. Perhaps this could be
>> implemented as a user defined BayModel that has a parent_id set to the uuid
>> of a parent baymodel. When we instantiate one, we would merge the two into
>> a single resource.
>>
>>  All of this is about anticipating possible future features. The only
>> reason I am mentioning this is that I want us to think about where we might
>> go with resource sharing so that our name uniqueness decision does not
>> preclude us from later going in this direction.
>>
>>  Adrian
>>
>>
>>>  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)
>>
>>
>> __________________________________________________________________________
>> 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)
>



-- 
Thanks,

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


More information about the OpenStack-dev mailing list