Open Stack

On 03/09/2015 01:26 PM, Mike Bayer wrote:
> Im about -1000 on disabling foreign key constraints.
So was I.  We didn't do it out of performance.

Since I am responsible for tipping over this particular cow, let me explain.

No, is too much. Let me sum up.

In the murky past, Keystone was primarily the identity back end.  I 
start with users, then tenant, and then it grew to have roles.

If this has stayed all in a SQL back end, you bet your sweet bippy I'd 
have left the integrity constraints in place.  THere is a big reason it 
didn't.

My first hack in Keystone was putting LDAP support back in, after the 
Keysteon Light rewrite pulled it out.  Back then, I waws warned that 
LDAP was different, and I kind of knew that it was, but I tried to do 
everything in LDAP we were doing in SQl, and, while the solution was 
bogus, it kindof worked if you squinted and were able to accept putting 
service users in your active directory.

Oh, and didn't want to write to it.  I mean, sure, there was writable 
LDAP. BUt people don't use L:DAP that way.  LDAP is maintained by 
corporate IT...which really means HR.  Bottom line is that the OpenStack 
lab people are not going to be writing projects into their LDAP servers.

At the same time, the abstractions were growing.  We added groups, 
domains, and role assignments.  Federation was in the distance, and 
mapping had to go somewhere.

At the Protland summit, a few conversation made it clear that we needed 
to split the Identity backend into a read only LDAP portion and a SQL 
writable portion.  Oh, sure, you could still keep users in SQL, and many 
people wanted to, but  LDAP was the larger concern, and, again, we knew 
federation was coming with similar constraints. So, a FK from the 
role-assignments table into the proejct table would be OK,  but now to 
either users or groups:  if thiose were in LDAP, there would be nothing 
there, and the constraint could not be met.


We've gone even further this release.  The assignments backend itself is 
being split up.  TBGH, I don't know if this is an essential split, but 
some of the main Keystone developers have worked really hard to make it 
work, and to show how Keystone specific data (role assignments)  can be 
kept separate from the projects and domains.

So, no, we are not talking performance.  We are talking architecture and 
functionality.  Keystone, with few exceptions, does not own the user 
database.  Keystone consumes it.  As time goes on, Keystone will do a 
better job of consume pre-existing data, and minimizing the amount of 
custom data it manages.

Does that make more sense?