<div dir="ltr"><div><br></div>Some comments and questions in line. Thanks.<br><div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-03 11:27 GMT+08:00 Adrian Otto <span dir="ltr"><<a href="mailto:adrian.otto@rackspace.com" target="_blank">adrian.otto@rackspace.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
Eric,
<div><br>
<div><span class="">
<blockquote type="cite">
<div>On Jun 2, 2015, at 10:07 PM, Eric Windisch <<a href="mailto:eric@windisch.us" target="_blank">eric@windisch.us</a>> wrote:</div>
<br>
<div>
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Jun 2, 2015 at 10:29 PM, Adrian Otto <span dir="ltr">
<<a href="mailto:adrian.otto@rackspace.com" target="_blank">adrian.otto@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">I have reflected on this further and offer this suggestion:
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<div><br>
</div>
<div>For what it's worth, I also believe that requiring manual specification of names, especially if they must be unique is an anti-pattern.</div>
<div><br>
</div>
<div>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.
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div></span>
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:</div>
<div><br>
</div>
<div>bay_name_generation_strategy = <random_readable | uuid></div>
<div>baymodel_name_generation_strategy = <random_readable | uuid></div>
<div><br>
</div>
<div>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.</div></div></div></blockquote><div>+1 on not optimize for this <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>
<div><span class=""><br>
<blockquote type="cite">
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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.</div>
<div><br>
</div>
<div>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).</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div></span>
Cool idea!</div></div></div></blockquote><div>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.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>
<div><br>
</div>
<div>Adrian</div>
<div><br>
<blockquote type="cite">
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Regards,</div>
<div>Eric Windisch</div>
</div>
</div>
</div><span class="">
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">
OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</span></div>
</blockquote>
</div>
<br>
</div>
</div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Thanks,<br><br></div>Jay Lau (Guangya Liu)<br></div></div></div></div>
</div></div></div>