Open Stack

Excerpts from Jay Pipes's message of 2014-02-28 14:26:26 -0800:
> 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.

+1. A Keystone record belongs to Keystone, and it should have a Keystone
ID. External records that are linked should be linked separately.

It may not be obvious to everyone, but MySQL uses B-trees for indexes.
B-trees cannot have variable-length keys. So varchar(64) means 64-byte
index keys. If you aren't careful and let that column be stored as utf-8,
this actually means *192* byte index keys, because MySQL uses 3-byte
utf-8 and thus a 64 "character" column could have 192 bytes. This does
not scale well as you are doing index scans and range lookups, not to
mention just generally raising memory and I/O pressure on the server.

What Jay is suggesting is that we actually be opinionated and store
Keystone users with 16-byte binary UUID's, and only ever use the UUID (in
the 32-byte text notation where appropriate) when returning a keystone ID.

Then only the initial authentication step where the user presents
external identification requires access to anything larger, allowing
all other Keystone operations to perform much better and keeping the
keystone database footprint smaller.