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
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)