Open Stack

There are several different points being raised here,
all very interesting. Trying to separate them below.

1) Using objects as an abstraction for versioned data:
   This seems like a good direction overall, especially from the point-of-view
   of backwards compatibility of consumers of the object. However, after looking through some
   of the objects defined in nova/objects/, I am not sure if I understand how
   this works. Specifically, it is not clear to me how might the consumer of the 
   object be able to query different versions of it at runtime.


2) Using objects as an abstraction to support different kinds of backends
   (SQL and non-SQL backends):
   - Again, a good direction overall. From implementation point-of-view though
   this may become tricky, in the sense that the object layer would need to be
   designed with just the right amount of logic so as to be able to work with either 
   a SQL or a non-SQL backend. It will be good to see some examples of how this might 
   be done if there are any existing examples somewhere.


3) From Solum's point-of-view, the concern around the potential downtime
   that may be incurred in the API-layer because of breaking object model changes,
   and so, investigating how to design this correctly right from the start.
   - This is a valid concern. We will have to design for this at sometime or other anyways.
   Doing this first up might be good with regards to understanding how the decision of
   using versioned objects would tie with the API layer implemented in Pecan+WSME.
   I don't have much experience with either, so would love to hear about it from those who do.


Best Regards,
Devdatta


-----Original Message-----
From: "Clayton Coleman" <ccoleman at redhat.com>
Sent: Thursday, November 7, 2013 8:26pm
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
Cc: "Dan Smith" <dms at danplanet.com>
Subject: Re: [openstack-dev] [Solum] Some initial code copying for db/migration

----- 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 at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev