Open Stack

Excerpts from Dolph Mathews's message of 2014-03-10 12:43:52 -0700:
> For posterity, I assume this thread is related to:
> 
> 
> http://lists.openstack.org/pipermail/openstack-dev/2014-February/028125.html
> 
> Anyway, keystone itself has issued 36-char tenant ID's in the past (diablo,
> I believe, if not essex as well). Something like this:
> 
>   $ python -c "import uuid; s = str(uuid.uuid4()); print s; print len(s);"
>   1b54024b-7c62-494e-9a34-6138e04e3dc7
>   36
> 
> Migrations to essex also pulled in existing tenant ID's from other
> pre-existing data sources. Most importantly, keystone is able to read
> tenants from backends such as LDAP, and you're welcome to write your own
> driver and return whatever data you want as an ID.
> 
> From an API perspective, keystone assumes that tenant ID's are URL-safe and
> globally unique, but does nothing to enforce either of those. Perhaps
> that's somewhere keystone could start (emit a warning if that's not the
> case?), before other services make stricter assumptions about the
> constraints around tenant ID's.

So, are you saying varchar(256) may be _too small_ ?