<div dir="ltr">For posterity, I assume this thread is related to:<div><br></div><div>  <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-February/028125.html">http://lists.openstack.org/pipermail/openstack-dev/2014-February/028125.html</a></div>

<div><br></div><div>Anyway, keystone itself has issued 36-char tenant ID's in the past (diablo, I believe, if not essex as well). Something like this:</div><br>  $ python -c "import uuid; s = str(uuid.uuid4()); print s; print len(s);"<br>

  1b54024b-7c62-494e-9a34-6138e04e3dc7<br>  36<div><br></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>Note: all of the above applies equally to user ID's, as well!</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 10, 2014 at 12:53 PM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">While looking into this bug:<br>
<br>
<a href="https://bugs.launchpad.net/heat/+bug/1290274" target="_blank">https://bugs.launchpad.net/heat/+bug/1290274</a><br>
<br>
I was trying to find out why the original developers felt that tenant_ids<br>
should be a 'varchar(256)'. In addition to moving from a regular varchar<br>
into a text field, varchar(256) in MySQL will become a tinytext which<br>
causes all sorts of performance issues, this just seems a _lot_ bigger<br>
than anything I've ever seen shown as a tenant/project id. I'd expect at<br>
worst varchar(64). Also it is probably safe to store as varbinary since<br>
we don't ever sort on it or store case-insensitive equivalents to it.<br>
<br>
So I was wondering where users can go to find out what to expect in<br>
that field. I dug through the API documentation for Keystone and I see<br>
nothing that really would constituate a format or even length. But maybe<br>
I'm just not looking in the right place. Thanks!<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>
</blockquote></div><br></div>