On Tue, Feb 25, 2014 at 11:47:43AM -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).
Hmm, my immediate reaction is there must be a better way than mangling both bits of data into the ID field, considering pretty much everything everywhere else in openstack uses uuids for user-visible object identifiers. > 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. > > 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. Yes, this will affect Heat in at least one place - we store the trustor user ID when we create a trust between the stack owner and the heat service user: https://github.com/openstack/heat/blob/master/heat/db/sqlalchemy/migrate_repo/versions/027_user_creds_trusts.py#L23 IMHO this is coming pretty late in the cycle considering the potential impact, but if this is definitely happening we can go ahead an update our schema. Steve _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
