----- Original Message ----- > +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.
Yeah, base abstract class / interface / field definitions, with a subclass implementation that is accessed via a factory/lookup table. I had started on that track but wanted to get the remotability feedback early (I don't like mucking around with the sqlalchemy metaclasses early on unless it's something we view as critical). The remotable path would separate the orm model and then do the same translation that happens today in nova/ironic with _from_db_object where we create two objects, then copy them back and forth a bunch. The first implementation could be converted to the second, I don't see the second being something we'd convert to the first since it's more work. I've also included examples of live schema update with the three states (old schema, new schema but write-only, new schema and no access to the old schema) for various types of changes (rename, split columns, add subtable relationship). I could do both to compare but figured we could argue out remotability via ML. > > 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
