Open Stack

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.

Note: all of the above applies equally to user ID's, as well!


On Mon, Mar 10, 2014 at 12:53 PM, Clint Byrum <clint at fewbar.com> wrote:

> While looking into this bug:
>
> https://bugs.launchpad.net/heat/+bug/1290274
>
> I was trying to find out why the original developers felt that tenant_ids
> should be a 'varchar(256)'. In addition to moving from a regular varchar
> into a text field, varchar(256) in MySQL will become a tinytext which
> causes all sorts of performance issues, this just seems a _lot_ bigger
> than anything I've ever seen shown as a tenant/project id. I'd expect at
> worst varchar(64). Also it is probably safe to store as varbinary since
> we don't ever sort on it or store case-insensitive equivalents to it.
>
> So I was wondering where users can go to find out what to expect in
> that field. I dug through the API documentation for Keystone and I see
> nothing that really would constituate a format or even length. But maybe
> I'm just not looking in the right place. Thanks!
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140310/7c18fd04/attachment.html>