Adam Young <ayo...@redhat.com> wrote:
> 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?
Somewhat vaguely. If by "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 mean that we start with this:
create table project (
id integer primary key
)
create table users (
id integer primary key
)
create table groups (
id integer primary key
)
create table role_assignments (
id integer primary key
project_id integer references project(id)
)
and then we change it, such that we are really doing this:
create table role_assignments (
id integer primary key
project_or_group_or_user_id integer
)
if *that’s* what you mean, that’s known as a “polymorphic foreign key”, and
it is not actually a foreign key at all, it is a terrible antipattern started by
the PHP/Rails community and carried forth by projects like Django. For
details on how to correct for this pattern, I wrote about it many years ago
here:
http://techspot.zzzeek.org/2007/05/29/polymorphic-associations-with-sqlalchemy/.
SQLAlchemy has an example suite that illustrates several approaches to
mitigating this anti pattern which you can see here:
http://docs.sqlalchemy.org/en/rel_0_9/orm/examples.html#module-examples.generic_associations.
So if that’s what we mean, then that is exactly what I’m trying to target as
a “don’t do that” situation; it’s unnecessary and incorrect. LDAP and SQL
databases are obviously very different, so in order to achieve parity
between them, a lot of work has to be done on the SQL side in particular as
it is much more structured than LDAP. If we are diluting our SQL databases
to turn into amorphous, unstructured blobs, then I think that’s a very bad
idea and I’m not sure why relational databases have any place, when
unstructured solutions like MongoDB are readily available. I’d note that
LDAP servers themselves will often use relational storage as their actual
backend, and you can be assured these systems can make correct use of
normalization internally.
> __________________________________________________________________________
> 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
__________________________________________________________________________
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
