In 2bd88d30 we added a new column domain_id to the user table to
deduplicate the domain_id columns in the local_user and nonlocal_user
tables, and at that point made the user.domain_id column a foreign key
referencing the project.id column. This is a problem that led to
3d46c8a5 in which we removed the ability for the resource driver to be
pluggable, since we had linked two sql backends together and made them
reliant on one another.
This commit removes the foreign key constraint from the user table and
the identity_provider table. For the user table, the sqlalchemy model
never reflected this schema so we don't need to change the model. For
the identity_provider table, we need to update the model. In both cases,
we already enforce, at the manager layer, the constraint that the
domain_id needs to reference a real domain ID[1][2], so we do not need
to rely on this constraint at the database layer.
Reviewed: https:/ /review. opendev. org/687753 /git.openstack. org/cgit/ openstack/ keystone/ commit/ ?id=c4d60977881 ac2f014dc6e2eaa ba37892f075266
Committed: https:/
Submitter: Zuul
Branch: master
commit c4d60977881ac2f 014dc6e2eaaba37 892f075266
Author: Colleen Murphy <email address hidden>
Date: Wed Oct 9 16:30:33 2019 -0700
Drop project.id foreign keys
In 2bd88d30 we added a new column domain_id to the user table to
deduplicate the domain_id columns in the local_user and nonlocal_user
tables, and at that point made the user.domain_id column a foreign key
referencing the project.id column. This is a problem that led to
3d46c8a5 in which we removed the ability for the resource driver to be
pluggable, since we had linked two sql backends together and made them
reliant on one another.
This commit removes the foreign key constraint from the user table and
the identity_provider table. For the user table, the sqlalchemy model
never reflected this schema so we don't need to change the model. For
the identity_provider table, we need to update the model. In both cases,
we already enforce, at the manager layer, the constraint that the
domain_id needs to reference a real domain ID[1][2], so we do not need
to rely on this constraint at the database layer.
[1] https:/ /opendev. org/openstack/ keystone/ src/commit/ 43142e4470df976 a459a1a2e95cfb1 63afc42893/ keystone/ identity/ core.py# L935 /opendev. org/openstack/ keystone/ src/commit/ 43142e4470df976 a459a1a2e95cfb1 63afc42893/ keystone/ federation/ core.py# L73-L77
[2] https:/
Partial-bug: #1672713
Change-Id: I7c068e350811e2 2622d1f1e7d8b0a 55d4d7cab11