Open Stack

On Fri, Feb 28, 2014 at 2:26 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> On Fri, 2014-02-28 at 13:10 -0800, Mark Washenberger wrote:
> >
> > 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
>
> The first would be required for the real solution. The second and third
> are performance improvements.
>
> > Any of those could require a migration for existing IDs depending on
> > how your identity driver functions.
>
> Personally, I think to fix this issue permanently and properly,
> migrations for database schemas of Glance and Nova would indeed need to
> accompany a proposed patch that restricts the Keystone external user ID
> to only a UUID value.
>
> I entirely disagree with allowing non-UUID values for the user ID value
> that is exposed outside of Keystone. All other solutions (including the
> proposals to continue using the user_id fields with non-UUID values) are
> just hacks IMO.
>

I believe we have some agreement here. Other openstack services should be
able to use a strongly typed identifier for users. I just think if we want
to go that route, we probably need to create a new field to act as the
proper user uuid, rather than repurposing the existing field. It sounds
like many existing LDAP deployments would break if we repurpose the
existing field.


> Best,
> -jay
>
>
>
> _______________________________________________
> 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/2086a20e/attachment.html>