<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Mar 1, 2014 at 12:51 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 class="">On Fri, 2014-02-28 at 15:25 -0800, Mark Washenberger wrote:<br>
> I believe we have some agreement here. Other openstack services should<br>
> be able to use a strongly typed identifier for users. I just think if<br>
> we want to go that route, we probably need to create a new field to<br>
> act as the proper user uuid, rather than repurposing the existing<br>
> field. It sounds like many existing LDAP deployments would break if we<br>
> repurpose the existing field.<br>
<br>
</div>Hi Mark,<br>
<br>
Please see my earlier response on this thread. I am proposing putting<br>
external identifiers into a mapping table that would correlate a<br>
Keystone UUID user ID with external identifiers (of variable length).<br></blockquote><div><br></div><div>The thing you seem to be missing is that the current user-id attribute is an "external identifier" depending on the identity backend you're using today. For example in the LDAP driver it is the CN by default (which is ridiculous for a large number of reasons, but let's leave those aside.) So if you want to create a new, strongly typed internal uuid identifier that makes the db performance scream, more power to you. But it's going to have to be a new field.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Once authentication has occurred (with any auth backend including LDAP),<br>
Keystone would only communicate to the other OpenStack services the UUID<br>
user ID from Keystone. This would indeed require a migration to each<br>
non-Keystone service that stores the user IDs as-is from Keystone<br>
currently (such as Glance or Nova).<br>
<br>
Once the migrations are run, then only UUID values would be stored, and<br>
further migrations could be run that would streamline the columns that<br>
stores these user IDs to a more efficient CHAR(32) or BINARY(16)<br>
internal storage format.<br>
<br>
Hope that clears things up.<br>
<div class="HOEnZb"><div class="h5"><br>
Best,<br>
-jay<br>
<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>
</div></div></blockquote></div><br></div></div>