On Fri, Feb 28, 2014 at 10:39 AM, Henry Nash <hen...@linux.vnet.ibm.com>wrote:
> Hi Mark, > > So we would not modify any existing IDs, so no migration required. > Okay, I just want to be painfully clear--we're not proposing changing any of the current restrictions on the user-id field. We will not: - require it to be a uuid - encode it as binary instead of char - shrink its size below the current 64 characters Any of those could require a migration for existing IDs depending on how your identity driver functions. If I'm just being Chicken Little, please reassure me once more and I'll be quiet :-) > > 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 > > > > _______________________________________________ > 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
