Open Stack

[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.

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.

Thoughts?

-- 
david stanek
web: https://dstanek.com
twitter: https://twitter.com/dstanek