[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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev