Open Stack

On Sat, Mar 1, 2014 at 12:51 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> On Fri, 2014-02-28 at 15:25 -0800, Mark Washenberger wrote:
> > 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.
>
> Hi Mark,
>
> Please see my earlier response on this thread. I am proposing putting
> external identifiers into a mapping table that would correlate a
> Keystone UUID user ID with external identifiers (of variable length).
>

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.



>
> Once authentication has occurred (with any auth backend including LDAP),
> Keystone would only communicate to the other OpenStack services the UUID
> user ID from Keystone. This would indeed require a migration to each
> non-Keystone service that stores the user IDs as-is from Keystone
> currently (such as Glance or Nova).
>
> Once the migrations are run, then only UUID values would be stored, and
> further migrations could be run that would streamline the columns that
> stores these user IDs to a more efficient CHAR(32) or BINARY(16)
> internal storage format.
>
> Hope that clears things up.
>
> Best,
> -jay
>
>
> _______________________________________________
> 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/20140303/1667ed46/attachment.html>