+1 for ease of iteration till we decide on the model (and so not worry about remotability right now :)).
Just to verify that I understand the proposed strawman commit, it will use nova/object/* like hierarchy to define Solum specific domain objects in which specific methods would be exposed whose implementation will use sqlalchemy ORM calls internally. Sounds good to me. As long as we are able to discuss and debate the perceived advantages of the object approach (that it makes handling versioned data easier, and that it allows using sql and non-sql backends) we should be good. Btw, thanks for sending across link to the F1 paper. Regards, - Devdatta -----Original Message----- From: "Clayton Coleman" <ccole...@redhat.com> Sent: Wednesday, November 13, 2013 12:29pm To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Cc: "devdatta kulkarni" <devdatta.kulka...@rackspace.com> Subject: Re: [openstack-dev] [Solum] Some initial code copying for db/migration ----- 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
