Open Stack

> 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.

The object registry is handled by the metaclass in objects/base.py. It
automatically collects objects that inherit from NovaObject, and allows
multiple versions of the same object to exist. We don't have anything
that needs to specifically ask the registry directly for "foo object
version X", so there's no interface for doing that right now. We do,
however, have incoming objects over RPC that need to be re-hydrated,
with an "is this compatible" version check. We also have the ability to
downlevel an object using the obj_make_compatible() method. We are
planning to always roll the conductor code first, which means it can
take the newest version of an object from the schema (in whatever state
it's in) and backlevel it to the version being asked for by a remote RPC
client.

> 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.

We don't have any examples of using a non-SQL backend for general
persistence in Nova, which means we don't have an example of using
objects to hide it. If what NovaObject currently provides is not
sufficient to hide the intricacies of a non-SQL persistence layer, I
think it's probably best to build that on top of what we've got in the
object model.

> 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.

The ironic guys were mentioning that they'd like to have something a
little more native for WSME integration. I too am ignorant here, but I
think it sounded like they wanted some general way to take an object and
transform it into what gets exposed to the API client. Perhaps just a
pattern of standard methods on such objects would be sufficient. For
nova, maybe:

  class NovaAPIViewableThingy(NovaObject):
      def obj_api_view(self, context):
          if context.is_admin():
              return show_admin_stuff()
          else:
              return show_usery_stuff()

?

--Dan