Open Stack

Excerpts from Adam Young's message of 2014-03-03 23:06:58 -0800:
> On 03/03/2014 02:32 PM, Jay Pipes wrote:
> > On Mon, 2014-03-03 at 11:09 -0800, Vishvananda Ishaya wrote:
> >> On Mar 3, 2014, at 6:48 AM, Jay Pipes <jaypipes at gmail.com> wrote:
> >>
> >>> On Sun, 2014-03-02 at 12:05 -0800, Morgan Fainberg wrote:
> >>>> Having done some work with MySQL (specifically around similar data
> >>>> sets) and discussing the changes with some former coworkers (MySQL
> >>>> experts) I am inclined to believe the move from varchar  to binary
> >>>> absolutely would increase performance like this.
> >>>>
> >>>>
> >>>> However, I would like to get some real benchmarks around it and if it
> >>>> really makes a difference we should get a smart "UUID" type into the
> >>>> common SQLlibs (can pgsql see a similar benefit? Db2?) I think this
> >>>> conversation. Should be split off from the keystone one at hand - I
> >>>> don't want valuable information / discussions to get lost.
> >>> No disagreement on either point. However, this should be done after the
> >>> standardization to a UUID user_id in Keystone, as a separate performance
> >>> improvement patch. Agree?
> >>>
> >>> Best,
> >>> -jay
> >> -1
> >>
> >> The expectation in other projects has been that project_ids and user_ids are opaque strings. I need to see more clear benefit to enforcing stricter typing on these, because I think it might break a lot of things.
> > What does Nova lose here? The proposal is to have Keystone's user_id
> > values be UUIDs all the time. There would be a migration or helper
> > script against Nova's database that would change all non-UUID user_id
> > values to the Keystone UUID values.
> >
> > If there's stuff in Nova that would break (which is doubtful,
> > considering like you say, these are supposed to be "opaque values" and
> > as such should not have any restrictions or validation on their value),
> > then that is code in Nova that should be fixed.
> >
> > Honestly, we shouldn't accept poor or loose code just because "stuff
> > might break".
> Why do you think that UUIDs would be some sort of magic bullet?
> 
> Thus far, we've stated that IDs are opaque strings, and that they will 
> be URL safe.  Adding additional Database lokups on top of LDAP calls is 
> going to make LDAP code paths even more convoluted than they are now.  
> I'd like to avoid that. And I don't see the benefit.
> 

Each row in each table throughout OpenStack that has to treat the user
id from Keystone as an opaque ID must then store the keystone id as a 64
byte string. Being able to make it a 16 byte binary value means a
significant saving at scale.

If you're using LDAP, you're only going to store that CN once per user,
and only going to look it up when said user tries to log in. After that,
the uuid will be passed around.

> 
> I'd be interested in hearing why CN is a bad default choice for LDAP; we 
> have to use a very high up theRFE chain object class by default and 
> didn't have that many attributes to chose from.
> 

CN is fine. External IDs of various shapes and sizes can be used. The
point is to make keystone get a little more opionated about its' id
strings in order to make the rest of OpenStack more scalable.