<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 28, 2014 at 2:26 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 Fri, 2014-02-28 at 13:10 -0800, Mark Washenberger wrote:<br>
><br>
> On Fri, Feb 28, 2014 at 10:39 AM, Henry Nash<br>
> <<a href="mailto:henryn@linux.vnet.ibm.com" target="_blank">henryn@linux.vnet.ibm.com</a>> wrote:<br>
>         Hi Mark,<br>
><br>
><br>
>         So we would not modify any existing IDs, so no migration<br>
>         required.<br>
><br>
><br>
> Okay, I just want to be painfully clear--we're not proposing changing<br>
> any of the current restrictions on the user-id field. We will not:<br>
>   - require it to be a uuid<br>
>   - encode it as binary instead of char<br>
>   - shrink its size below the current 64 characters<br>
<br>
</div>The first would be required for the real solution. The second and third<br>
are performance improvements.<br>
<div><br>
> Any of those could require a migration for existing IDs depending on<br>
> how your identity driver functions.<br>
<br>
</div>Personally, I think to fix this issue permanently and properly,<br>
migrations for database schemas of Glance and Nova would indeed need to<br>
accompany a proposed patch that restricts the Keystone external user ID<br>
to only a UUID value.<br>
<br>
I entirely disagree with allowing non-UUID values for the user ID value<br>
that is exposed outside of Keystone. All other solutions (including the<br>
proposals to continue using the user_id fields with non-UUID values) are<br>
just hacks IMO.<br></blockquote><div><br></div><div>I believe we have some agreement here. Other openstack services should be able to use a strongly typed identifier for users. I just think if we want to go that route, we probably need to create a new field to act as the proper user uuid, rather than repurposing the existing field. It sounds like many existing LDAP deployments would break if we repurpose the existing field.</div>
<div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best,<br>
-jay<br>
<div><div><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>
</div></div></blockquote></div><br></div></div>