Open Stack

Eric,

On Jun 2, 2015, at 10:07 PM, Eric Windisch <eric at windisch.us<mailto:eric at windisch.us>> wrote:



On Tue, Jun 2, 2015 at 10:29 PM, Adrian Otto <adrian.otto at rackspace.com<mailto:adrian.otto at 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.

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!

Adrian


Regards,
Eric Windisch
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150603/750f136c/attachment.html>