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_ ? _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
