On Wed, Feb 26, 2014 at 5:25 AM, Dolph Mathews <[email protected]>wrote:
> > On Tue, Feb 25, 2014 at 2:38 PM, Jay Pipes <[email protected]> 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 >> > [email protected] >> > >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > [email protected] >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
