On Mon, 2014-03-03 at 11:18 -0800, Mark Washenberger wrote: > > > > On Sat, Mar 1, 2014 at 12:51 PM, Jay Pipes <jaypi...@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 _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev