On Fri, Feb 28, 2014 at 2:26 PM, Jay Pipes <[email protected]> wrote:
> On Fri, 2014-02-28 at 13:10 -0800, Mark Washenberger wrote: > > > > On Fri, Feb 28, 2014 at 10:39 AM, Henry Nash > > <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
