----- Original Message ----- > > > > https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L420 > > > > https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L43 > > This API and these models are what we are trying to avoid exposing to > the rest of nova. By wrapping these in our NovaObject-based structures, > we can bundle versioned data and methods together which is what we need > for cross-version compatibility and parity for the parts of nova that > are not allowed to talk to the database directly. > > See the code in nova/objects/* for the implementations. Right now, these > just call into the db_api.py, but eventually we want to move the actual > database implementation into the objects themselves and hopefully > dispense with most or all of the sqlalchemy/* stuff. This also provides > us the ability to use other persistence backends that aren't supported > by sqlalchemy, or that don't behave like it does. > > If you're going to be at the summit, come to the "objects" session on > Thursday where we'll talk about this in more detail. Other projects have > expressed interest in moving the core framework into Oslo so that we're > all doing things in roughly the same way. It would be good to get you > started on "the right way" early on before you have the migration hassle > we're currently "enjoying" in Nova :) > > --Dan >
The summit session was excellent - next step for me is to look through what the right abstraction is going to be for objects that keeps the db details properly isolated and the API surface on /objects suitably coarse (in line with the long discussion in Nova about non-SQL backends, the consensus of which is that the domain object model needs to abstract whole interaction flows, vs granular steps). I'll try to have some example code to debate after I get back from summit. Even assuming Solum has a fairly small persistence model, in the long run I believe it's fair to say that the ability to perform live upgrades will become critical for all operators. One of the side effects of supporting potentially millions of applications (at the high end, and not an unreasonable estimate for hosted environments) is that any period of downtime at the API level will prevent users from making deployments, which is a direct line-of-business concern. Designing around live upgrades - specifically, the requirement that code must be aware of two versions of a schema at the same time - implies that the domain model must be able to be aware of those versions on an object basis. For reference, [1] and [2] contain some of the Nova discussion, and Nova in icehouse is going to be moving this way. I'd prefer (it's important to Red Hat) to design for that from the beginning and be working towards that end. Do folks have additional questions or concerns about my exploration of a versioned domain object model from day one? Are there others who would like to embrace quick and dirty and explicitly ignore this issue until we have a Solum prototype running? [1] https://etherpad.openstack.org/p/NovaIcehouseSummitUpgrades [2] https://etherpad.openstack.org/p/NovaIcehouseSummitObjects _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
