Open Stack

On Mon, 2014-03-03 at 11:18 -0800, Mark Washenberger wrote:
> 
> 
> 
> 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.

No, it won't. The proposal is to create a new table that maps a UUID
value to the external identifier value.

The migration would essentially do this pseudocode:

recs = get_identity_records()
for rec in recs:
  if not is_like_uuid(rec.user_id):
      external_id = rec.user_id
      new_uuid = uuid.uuid4()
      insert_into_external_ids(new_uuid, external_id)
      rec.user_id = new_uuid
      save_identity_record(rec)

Cascading updates on the user_id field to its child relations will take
care of the changes in user_id column in foriegn keys.

A migration script in, say, Nova, would do something like:

UPDATE instances SET owner_id = ext.user_id
FROM instances JOIN keystone.external_id_mapping ext
ON instances.owner_id = ext.external_id;

Best,
-jay