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....@gmail.com>: > 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) > -- 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