c4d6097788
In2bd88d30we 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 to3d46c8a5in 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]43142e4470/keystone/identity/core.py (L935)[2]43142e4470/keystone/federation/core.py (L73-L77)Partial-bug: #1672713 Change-Id: I7c068e350811e22622d1f1e7d8b0a55d4d7cab11
10 lines
415 B
YAML
10 lines
415 B
YAML
---
|
|
upgrade:
|
|
- |
|
|
The foreign key constraint between the ``user.domain_id`` column and the
|
|
``project.id`` column and between the ``identity_provider.domain_id``
|
|
column and the ``project.id`` column will be dropped upon running the
|
|
keystone db_sync contraction step. These constraints are enforced in code
|
|
and do not need to be enforced by the database. This should have no impact
|
|
on users.
|