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?



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to