Open Stack

Some comments and questions in line. Thanks.

2015-06-03 11:27 GMT+08:00 Adrian Otto <adrian.otto at rackspace.com>:

>  Eric,
>
>  On Jun 2, 2015, at 10:07 PM, Eric Windisch <eric at windisch.us> wrote:
>
>
>
> On Tue, Jun 2, 2015 at 10:29 PM, Adrian Otto <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.
>
+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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,

Jay Lau (Guangya Liu)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150604/4bb91ae7/attachment.html>