[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
Thu Jun 4 06:14:08 UTC 2015
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150604/d62d8cb6/attachment-0001.html>
More information about the OpenStack-dev
mailing list