[Ovirt-devel] [PATCH server] Revised attempt at refactoring the vm_controller using the service layer.

[David Lutterkort]

On Thu, 2009-04-23 at 08:46 -0700, Ian Main wrote:
> So it sounds like your concern regarding long lived objects should be 
> taken care of.  Somewhere in there though it would be nice to have a
> class that looks something like the schema we're implementing.. even if
> it gets instantiated for every request.

It highly depends on what the agent framework will like best - since
we're really just returning a list of property values, I think there's
no point in making the QMF 'object' at that level more than a hash plus
some sort of tag for the QMF-level class.

> Also, somehow we're going to need a way to map IDs to records in the
> database on a per-agent-instance basis (eg they can change across
> restarts of the agent).  I could create some kind of mapping in memory
> or we could add fields to the active records.. It may be possible to
> make them persistent too, not sure on that one.

Since we (the ovirt side of the agent) generate all the objects, it
would be nice if we could embed our own idea of an 'id' into the
QMF-level object; in most cases, this would just be the id of the AR
object, but we can make the mapping vary with the QMF class of the
object[1]

To sketch this out a little more, the representation of QMF objects that
is used to communicate between the QMF agent framework and the ovirt
(Ruby) agent code should look something like

     class QMF::Agent::ObjectID
       # The notion of identity for this object; the agent framework
          # is expected to preserve it across uses of the same object,
          # for example, in a call sequence where one QMF call produces
        the
          # object, and the next QMF call calls a method on that object
          # 
          # Type is TBD, depending on what QMF lets us embed in the QMF objectID
          attr_reader :local_id
        
          # The QMF-level class - just a string like 'VmDef'
          attr_reader :qmf_class_name
        
          # We might want to expose more of the QMF objectID to the
        agent
          # impl, though I don't think there's much need for that just
        yet.
          # The difficulty is that for ObjectID instances created by
          # the agent impl, we'd need to call back into the agent
        framework
          # to calculate the QMF objectID
        end

        class QMF::Agent::Object
          # Hash mapping property name -> value. The type of value
          # needs to be compatible with the type from the QMF API spec
          #
          # Changing entries in this hash does _not_ change anything
          # in the underlying objects in the DB. For that, we expect
          # a callback in the actual agent
          attr_reader :properties
        
          # An instance of QMF::Agent::ObjectID
          attr_reader :object_id
        end
        
With that, when the QMF agent framework calls a method in the agent impl
in the QMF controller, it passes instances of QMF::Agent::ObjectID for
all arguments that have type 'objID' in the QMF API spec, and receives
instances of QMF::Agent::Object for method results that are of type
'objID'.

For dealing with properties, setters seems easy: one method set_property
that takes a QMF::Agent::ObjectID, a symbol (the name of the property)
and an object (the new value).

I am not sure there is a point for explicit property getters, since the
agent framework only needs them (a) when a new object is returned from
the agent impl and (b) when a property changes. In case (a), we already
return them as part of the QMF::Agent::Object, for (b) we need a
notification from the agent impl to the agent framework, i.e. something
initiated by the agent impl.

For case (b), somebody also needs to decide whether a property change
needs to be sent out - we can either have the agent impl tell the
framework about every single property update, and leave filtering of
unneeded updates to the framework, or do the filtering in the agent
impl. Obviously, I'd prefer the former option :)

Besides the above, we also need to figure out some sort of dispatch
mechanism within the agent impl, i.e. the agent framework will call the
same thing regardless of the type of the QMF object; we need to dispatch
that to the various QMF controllers, though I don't think that that's
too difficult, and we want that inside the agent impl anyway to control
the lifecycle of the QMF controller.

David