Thanks Adrian, I see. Clear now. 2015-06-04 11:17 GMT+08:00 Adrian Otto <adrian.o...@rackspace.com>:
> Jay, > > On Jun 3, 2015, at 6:42 PM, Jay Lau <jay.lau....@gmail.com> wrote: > > Thanks Adrian, some questions and comments in-line. > > 2015-06-03 10:29 GMT+08:00 Adrian Otto <adrian.o...@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....@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....@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....@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.o...@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....@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@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@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >>>> <http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe >>> <http://openstack-dev-requ...@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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev