<div dir="ltr">Just to illustrate the discussion, we have a bug fix that currently tries to drop a FK between the federation and identity subsystems [1].<div><br></div><div>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 protocol or an identity provider is deleted [2].</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/445505/">https://review.openstack.org/#/c/445505/</a></div><div>[2] <a href="https://review.openstack.org/#/c/420893/">https://review.openstack.org/#/c/420893/</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 12, 2017 at 11:58 AM, Lance Bragstad <span dir="ltr"><<a href="mailto:lbragstad@gmail.com" target="_blank">lbragstad@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Apr 12, 2017 at 9:28 AM, David Stanek <span dir="ltr"><<a href="mailto:dstanek@dstanek.com" target="_blank">dstanek@dstanek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[tl;dr I want to remove the artificial restriction of not allowing FKs between<br>
subsystems and I want to stop FK enforcement in code.]<br>
<br>
The keystone code architecture is pretty simple. The data and functionality are<br>
divided up into subsystems. Each subsystem can be configured to use a different<br>
backend datastore. Of course, there are always exceptions to the rule like how<br>
the federation and identity subsystems are highly coupled in the data model.<br>
<br>
On the surface this flexible model sounds good, but there are some interesting<br>
consequences. First, you can't tell from looking at the data model that there<br>
actually is a lot of coupling between the subsystems. So instead of looking at<br>
our sqlalchemy models to see relationships, we must look throughout the code<br>
for where a particular primary key is used and look for enforcement. (Hopefully<br>
we enforce it in all of the right places.) Additionally, a DBA/data architect/<br>
whenever can't see the relationship at all by looking at the database.<br>
<br>
Second, this has polluted our code and causes erroneous API errors. We have added<br>
lots of get_*() calls in our code that checks for the existence of IDs in<br>
another subsystem. In some cases we probably don't do the check and thus would<br>
allow bad data to be stored. The check often causes 404s instead of 400s when<br>
bad data is provided.<br></blockquote><div><br></div></span><div>Having these cleaned up would be awesome. I imagine we'd also see some sort of performance benefit as a result, too.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So I'd like us to be more deliberate in defining which parts of the data model<br>
are truly independent and a separate backend datastore would make sense. For<br>
instance, we know we want to support LDAP for identity (although this still puts<br>
identity info into a SQL database) and catalog is very isolated from the rest of<br>
the data model.<br>
<br>
As a side effect this means that if deployers wished to use a separate backend<br>
for something they would need to also implement it for the other highly coupled<br>
subsystems. They would also have to provide any FK enforcement that their own<br>
datastore does not provide.<br></blockquote><div><br></div></span><div>So for deployers, this would mean that if today they only deploy keystone backed with LDAP for *only* identity, tomorrow they will have to ensure that LDAP has all the proper things for other subsystems that use to have an in-code constraint with identity (i.e. assignment). I wonder how many folks that would be? What would an upgrade look like for deployments wishing to stick to LDAP? I imagine we'd be raising the bar for that particular upgrade.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thoughts?<br>
<span class="m_-8076384097373463402HOEnZb"><font color="#888888"><br>
--<br>
david stanek<br>
web: <a href="https://dstanek.com" rel="noreferrer" target="_blank">https://dstanek.com</a><br>
twitter: <a href="https://twitter.com/dstanek" rel="noreferrer" target="_blank">https://twitter.com/dstanek</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</font></span></blockquote></span></div><br></div></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><font color="#666666">Rodrigo Duarte Sousa<br></font></div><div><font color="#666666">Senior Quality Engineer @ Red Hat<br></font></div><div dir="ltr"><div><div><span style="color:rgb(102,102,102)">MSc</span><span style="color:rgb(102,102,102)"></span><span style="color:rgb(102,102,102)"> in Computer Science</span><br><font color="#3333ff"><a href="http://rodrigods.com" target="_blank">http://<font color="#3333ff">rodrigods.com</font></a></font></div></div></div></div></div></div></div></div></div></div></div></div>
</div>