Some comments and questions in line. Thanks. 2015-06-03 11:27 GMT+08:00 Adrian Otto <adrian.o...@rackspace.com>:
> Eric, > > On Jun 2, 2015, at 10:07 PM, Eric Windisch <e...@windisch.us> wrote: > > > > On Tue, Jun 2, 2015 at 10:29 PM, Adrian Otto <adrian.o...@rackspace.com> > wrote: > >> 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. >> > > For what it's worth, I also believe that requiring manual specification > of names, especially if they must be unique is an anti-pattern. > > If auto-generation of human readable names is performed and these must > be unique, mind that you will be accepting a limit on the number of bays > that may be created. > > > Good point. Keeping in mind that the effective limit would be per-tenant, > and a simple mitigation could be used (adding incrementing digits or hex to > the end of the name in the case of multiple guesses with collisions) could > make the effective maximum high enough that it would be effectively > unlimited. If someone actually reached the effective limit, the cloud > provider could advise the user to specify a UUID they create as the name in > order to avoid running out of auto-generated names. I could also imagine a > Magnum feature that would allow a tenant to select an alternate name > assignment strategy. For example: > > bay_name_generation_strategy = <random_readable | uuid> > baymodel_name_generation_strategy = <random_readable | uuid> > > Where uuid simply sets the name to the uuid of the resource, > guaranteeing an unlimited number of bays at the cost of readability. If > this were settable on a per-tenant basis, you’d only need to use it for > tenants with ridiculous numbers of bays. I suggest that we not optimize for > this until the problem actually surfaces somewhere. > +1 on not optimize for this > > I think this is perfectly fine, as long as it's reasonably large and > the algorithm is sufficiently intelligent. The UUID algorithm is good at > this, for instance, although it fails at readability. Docker's is not > terribly great and could be limiting if you were looking to run several > thousand containers on a single machine. Something better than Docker's > algorithm but more readable than UUID could be explored. > > Also, something to consider is if this should also mean a change to the > UUIDs themselves. You could use UUID-5 to create a UUID from your tenant's > UUID and your unique name. The tenant's UUID would be the namespace, with > the bay's name being the "name" field. The benefit of this is that clients, > by knowing their tenant ID could automatically determine their bay ID, > while also guaranteeing uniqueness (or as unique as UUID gets, anyway). > > > Cool idea! > I'm clear with the solution, but still have some questions: So we need to set the bay/baymodel name in the format of UUID-name format? Then if we get the tenant ID, we can use "magnum bay-list | grep <tenant-id>" or some other filter logic to get all the bays belong to the tenant? By default, the "magnum bay-list/baymodel-list" will only show the bay/baymodels for one specified tenant. > > Adrian > > > Regards, > Eric Windisch > > __________________________________________________________________________ > 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
