----- Original Message ----- > > The abstraction will probably always leak something, but in general it comes > down to isolating a full transaction behind a coarse method. Was going to > try to demonstrate that as I went. >
I've almost got something ready for feedback and review - before I do that I wanted to follow up with remotability and it's relative importance: Is remotability of DB interactions a prime requirement for all OpenStack services? Judging by what I've seen so far, it's primarily to ensure that DB passwords are isolated from the API code, with a tiny amount of being able to scale business logic independently. Are there other reasons? For DB password separation, it's never been a huge concern to us operationally - do others have strong enough opinions either way to say that it continues to be important vs. not? For the separated scale behavior, at the control plane scale outs we suspect we'll have (2-20?), does separating the api and a background layer provide benefit? The other items that have been mentioned that loosely couple with remotability are versioned upgrades, but we can solve those in a combined layer as well with an appropriately chosen API abstraction. If remotability of DB calls is not a short term or medium term objective, then I was going to put together a strawman commit that binds domain object implementation subclasses that are tied to sqlalchemy ORM, but with the granular create/save/update calls called out and enforced. If it is a short/medium objective, we'd use the object field list to copy from the ORM, with the duplicate object creation that it entails. The former is easier to iterate on as we develop to decide on the model, the latter is easier to make remoteable (can't have the SQL orm state inside the object that is being serialized easily). There's an argument the latter enforces stronger code guarantees as well (there's no way for people to use tricky orm magic methods added to the object, although that's a bit less of an issue with sqlalchemy than other models). Thoughts? _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
