<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 28, 2014 at 10:39 AM, Henry Nash <span dir="ltr"><<a href="mailto:henryn@linux.vnet.ibm.com" target="_blank">henryn@linux.vnet.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Mark,<div><br></div><div>So we would not modify any existing IDs, so no migration required.</div>
</div></blockquote><div><br></div><div>Okay, I just want to be painfully clear--we're not proposing changing any of the current restrictions on the user-id field. We will not:</div><div> - require it to be a uuid</div>
<div> - encode it as binary instead of char</div><div> - shrink its size below the current 64 characters</div><div><br></div><div>Any of those could require a migration for existing IDs depending on how your identity driver functions.</div>
<div><br></div><div>If I'm just being Chicken Little, please reassure me once more and I'll be quiet :-)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><span class="HOEnZb"><font color="#888888"><div><br></div></font></span><div><span class="HOEnZb"><font color="#888888">Henry</font></span><div><div class="h5"><br><div><div>On 28 Feb 2014, at 17:38, Mark Washenberger <<a href="mailto:mark.washenberger@markwash.net" target="_blank">mark.washenberger@markwash.net</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 26, 2014 at 5:25 AM, Dolph Mathews <span dir="ltr"><<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@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 dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div>On Tue, Feb 25, 2014 at 2:38 PM, Jay Pipes <span dir="ltr"><<a 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>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><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><div><br></div><div>Is this approach planning on reusing the existing user-id field, then? It seems like this creates a migration problem for folks who are currently using user-ids that are generated by their identity backends.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><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><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><br>
> The review that would implement this change in size<br>
> is <a 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 href="mailto:m@metacloud.com" target="_blank">m@metacloud.com</a><br>
><br>
><br>
</div>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br></blockquote></div><br></div></div>
_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></div></div></div><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>
<br></blockquote></div><br></div></div>