Open Stack

On Fri, Feb 28, 2014 at 10:39 AM, Henry Nash <henryn at 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.washenberger at markwash.net> wrote:
>
>
>
>
> 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
>>
>>
> _______________________________________________
> 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/1b34a131/attachment.html>