Hi Mark, So we would not modify any existing IDs, so no migration required.
Henry On 28 Feb 2014, at 17:38, Mark Washenberger <mark.washenber...@markwash.net> wrote: > > > > On Wed, Feb 26, 2014 at 5:25 AM, Dolph Mathews <dolph.math...@gmail.com> > wrote: > > On Tue, Feb 25, 2014 at 2:38 PM, Jay Pipes <jaypi...@gmail.com> wrote: > On Tue, 2014-02-25 at 11:47 -0800, Morgan Fainberg wrote: > > For purposes of supporting multiple backends for Identity (multiple > > LDAP, mix of LDAP and SQL, federation, etc) Keystone is planning to > > increase the maximum size of the USER_ID field from an upper limit of > > 64 to an upper limit of 255. This change would not impact any > > currently assigned USER_IDs (they would remain in the old simple UUID > > format), however, new USER_IDs would be increased to include the IDP > > identifier (e.g. USER_ID@@IDP_IDENTIFIER). > > -1 > > I think a better solution would be to have a simple translation table > only in Keystone that would store this longer identifier (for folks > using federation and/or LDAP) along with the Keystone user UUID that is > used in foreign key relations and other mapping tables through Keystone > and other projects. > > Morgan and I talked this suggestion through last night and agreed it's > probably the best approach, and has the benefit of zero impact on other > services, which is something we're obviously trying to avoid. I imagine it > could be as simple as a user_id to domain_id lookup table. All we really care > about is "given a globally unique user ID, which identity backend is the user > from?" > > On the downside, it would likely become bloated with unused ephemeral user > IDs, so we'll need enough metadata about the mapping to implement a purging > behavior down the line. > > Is this approach planning on reusing the existing user-id field, then? It > seems like this creates a migration problem for folks who are currently using > user-ids that are generated by their identity backends. > > > > The only identifiers that would ever be communicated to any non-Keystone > OpenStack endpoint would be the UUID user and tenant IDs. > > > There is the obvious concern that projects are utilizing (and storing) > > the user_id in a field that cannot accommodate the increased upper > > limit. Before this change is merged in, it is important for the > > Keystone team to understand if there are any places that would be > > overflowed by the increased size. > > I would go so far as to say the user_id and tenant_id fields should be > *reduced* in size to a fixed 16-char BINARY or 32-char CHAR field for > performance reasons. Lengthening commonly-used and frequently-joined > identifier fields is not a good option, IMO. > > Best, > -jay > > > The review that would implement this change in size > > is https://review.openstack.org/#/c/74214 and is actively being worked > > on/reviewed. > > > > > > I have already spoken with the Nova team, and a single instance has > > been identified that would require a migration (that will have a fix > > proposed for the I3 timeline). > > > > > > If there are any other known locations that would have issues with an > > increased USER_ID size, or any concerns with this change to USER_ID > > format, please respond so that the issues/concerns can be addressed. > > Again, the plan is not to change current USER_IDs but that new ones > > could be up to 255 characters in length. > > > > > > Cheers, > > Morgan Fainberg > > — > > Morgan Fainberg > > Principal Software Engineer > > Core Developer, Keystone > > m...@metacloud.com > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
