Open Stack

On Wed, Feb 26, 2014 at 5:25 AM, Dolph Mathews <dolph.mathews at gmail.com>wrote:

>
> On Tue, Feb 25, 2014 at 2:38 PM, Jay Pipes <jaypipes at 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 at metacloud.com
>> >
>> >
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev at lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140228/a7867fee/attachment.html>