On Wed, Apr 12, 2017 at 9:28 AM, David Stanek <[email protected]> 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 subsystems. Each subsystem can be configured to use a > different > backend datastore. Of course, there are always exceptions to the rule like > how > the federation and identity subsystems are highly coupled in the data > model. > > On the surface this flexible model sounds good, but there are some > interesting > consequences. First, you can't tell from looking at the data model that > there > actually is a lot of coupling between the subsystems. So instead of > looking at > our sqlalchemy models to see relationships, we must look throughout the > code > for where a particular primary key is used and look for enforcement. > (Hopefully > we enforce it in all of the right places.) Additionally, a DBA/data > architect/ > whenever can't see the relationship at all by looking at the database. > > Second, this has polluted our code and causes erroneous API errors. We > have added > lots of get_*() calls in our code that checks for the existence of IDs in > another subsystem. In some cases we probably don't do the check and thus > would > allow bad data to be stored. The check often causes 404s instead of 400s > when > bad data is provided. > Having these cleaned up would be awesome. I imagine we'd also see some sort of performance benefit as a result, too. > > So I'd like us to be more deliberate in defining which parts of the data > model > are truly independent and a separate backend datastore would make sense. > For > instance, we know we want to support LDAP for identity (although this > still puts > identity info into a SQL database) and catalog is very isolated from the > rest of > the data model. > > As a side effect this means that if deployers wished to use a separate > backend > for something they would need to also implement it for the other highly > coupled > subsystems. They would also have to provide any FK enforcement that their > own > datastore does not provide. > 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. > > Thoughts? > > -- > david stanek > web: https://dstanek.com > twitter: https://twitter.com/dstanek > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
