<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 02/26/2014 08:25 AM, Dolph Mathews
wrote:<br>
</div>
<blockquote
cite="mid:CAC=h7gXuygaCPUyTeiAyD1m6aQC-W3b=v305LeT-YF8D13FyeQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Feb 25, 2014 at 2:38 PM, Jay
Pipes <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">On Tue, 2014-02-25 at 11:47 -0800, Morgan
Fainberg wrote:<br>
> For purposes of supporting multiple backends for
Identity (multiple<br>
> LDAP, mix of LDAP and SQL, federation, etc)
Keystone is planning to<br>
> increase the maximum size of the USER_ID field from
an upper limit of<br>
> 64 to an upper limit of 255. This change would not
impact any<br>
> currently assigned USER_IDs (they would remain in
the old simple UUID<br>
> format), however, new USER_IDs would be increased
to include the IDP<br>
> identifier (e.g. USER_ID@@IDP_IDENTIFIER).<br>
<br>
</div>
-1<br>
<br>
I think a better solution would be to have a simple
translation table<br>
only in Keystone that would store this longer identifier
(for folks<br>
using federation and/or LDAP) along with the Keystone user
UUID that is<br>
used in foreign key relations and other mapping tables
through Keystone<br>
and other projects.<br>
</blockquote>
<div><br>
</div>
<div>Morgan and I talked this suggestion through last night
and agreed it's probably the best approach, and has the
benefit of zero impact on other services, which is
something we're obviously trying to avoid. I imagine it
could be as simple as a user_id to domain_id lookup table.
All we really care about is "given a globally unique user
ID, which identity backend is the user from?"</div>
<div><br>
</div>
<div>On the downside, it would likely become bloated with
unused ephemeral user IDs, so we'll need enough metadata
about the mapping to implement a purging behavior down the
line.</div>
</div>
</div>
</div>
</blockquote>
UUIDs are 32 chars long. Its really just uuid@@uuid that pushes us
over the 64 character limit. <br>
If we can shorten up the IDP_ID we can fit everything in 64 chars
(which means only Nova needs to expand its column size)<br>
<br>
What if we enumerated IDPs by index, from 10000000 to 99999999 or
something comparable, and then use the new domain_index (or prot
domain id to not be a uuid). Then the above scheme would work and
no migration would be required.<br>
<br>
<br>
<blockquote
cite="mid:CAC=h7gXuygaCPUyTeiAyD1m6aQC-W3b=v305LeT-YF8D13FyeQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The only identifiers that would ever be communicated to
any non-Keystone<br>
OpenStack endpoint would be the UUID user and tenant IDs.<br>
<div class=""><br>
> There is the obvious concern that projects are
utilizing (and storing)<br>
> the user_id in a field that cannot accommodate the
increased upper<br>
> limit. Before this change is merged in, it is
important for the<br>
> Keystone team to understand if there are any places
that would be<br>
> overflowed by the increased size.<br>
<br>
</div>
I would go so far as to say the user_id and tenant_id
fields should be<br>
*reduced* in size to a fixed 16-char BINARY or 32-char
CHAR field for<br>
performance reasons. Lengthening commonly-used and
frequently-joined<br>
identifier fields is not a good option, IMO.<br>
<br>
Best,<br>
-jay<br>
<div class=""><br>
> The review that would implement this change in size<br>
> is <a moz-do-not-send="true"
href="https://review.openstack.org/#/c/74214"
target="_blank">https://review.openstack.org/#/c/74214</a>
and is actively being worked<br>
> on/reviewed.<br>
><br>
><br>
> I have already spoken with the Nova team, and a
single instance has<br>
> been identified that would require a migration
(that will have a fix<br>
> proposed for the I3 timeline).<br>
><br>
><br>
> If there are any other known locations that would
have issues with an<br>
> increased USER_ID size, or any concerns with this
change to USER_ID<br>
> format, please respond so that the issues/concerns
can be addressed.<br>
> Again, the plan is not to change current USER_IDs
but that new ones<br>
> could be up to 255 characters in length.<br>
><br>
><br>
> Cheers,<br>
> Morgan Fainberg<br>
> —<br>
> Morgan Fainberg<br>
> Principal Software Engineer<br>
> Core Developer, Keystone<br>
> <a moz-do-not-send="true"
href="mailto:m@metacloud.com">m@metacloud.com</a><br>
><br>
><br>
</div>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a moz-do-not-send="true"
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>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>