Open Stack

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