On 12-Apr 15:25, Rodrigo Duarte wrote:
> On Wed, Apr 12, 2017 at 2:47 PM, David Stanek wrote:
>
> > On 12-Apr 14:30, Rodrigo Duarte wrote:
> > > Just to illustrate the discussion, we have a bug fix that currently tries
> > > to drop a FK between the federation and identity subsystems [1].
> > >
>
On Wed, Apr 12, 2017 at 2:47 PM, David Stanek wrote:
> On 12-Apr 14:30, Rodrigo Duarte wrote:
> > Just to illustrate the discussion, we have a bug fix that currently tries
> > to drop a FK between the federation and identity subsystems [1].
> >
> > [1] https://review.openstack.org/#/c/445505/
>
>
On 12-Apr 14:30, Rodrigo Duarte wrote:
> Just to illustrate the discussion, we have a bug fix that currently tries
> to drop a FK between the federation and identity subsystems [1].
>
> [1] https://review.openstack.org/#/c/445505/
I think this highlights one of my problems with the current archit
Just to illustrate the discussion, we have a bug fix that currently tries
to drop a FK between the federation and identity subsystems [1].
The previous fix for this bug (which has been merged and had the backport
abandoned) took advantage of the FK in order to cascade delete federated
users when a
On Wed, Apr 12, 2017 at 9:28 AM, David Stanek wrote:
> [tl;dr I want to remove the artificial restriction of not allowing FKs
> between
> subsystems and I want to stop FK enforcement in code.]
>
> The keystone code architecture is pretty simple. The data and
> functionality are
> divided up into
[tl;dr I want to remove the artificial restriction of not allowing FKs between
subsystems and I want to stop FK enforcement in code.]
The keystone code architecture is pretty simple. The data and functionality are
divided up into subsystems. Each subsystem can be configured to use a different
back