Open Stack

I read the proposal and am very happy with where this is headed.  Some
comments on this rpc/oslo bits below ...

On 05/07/2013 04:21 PM, Mark McLoughlin wrote:
> On Tue, 2013-05-07 at 10:01 -0700, Dan Smith wrote:
>>> Wrt Oslo, the serialization hook needs to go in from the start,
>>> obviously, but I'd recommend developing the base object class in Nova
>>> in a way (e.g. by abstracting away nova-isms) that it can easily be
>>> moved to Oslo later at the moment when another project wants to use
>>> it. Starting it in oslo-incubator when no other projects are using it
>>> would just be unnecessary overhead for you.
>>
>> Cool, that sounds good to me.

I agree with the idea of only putting minimal bits in oslo to start
while we solidify things in nova.  Makes sense.

>> Right now, we embed special fields in the serialized version of the
>> object, such as "nova_object.name" (like the VERSION_KEY stuff does
>> with "oslo.version"). Should we go ahead and use "oslo" in such things
>> as we're cooking this up in nova so that the move to oslo is easy?
> 
> It depends whether you want it to be 'nova' or 'oslo' when this ends up
> in a proper library - the former makes sense where you want each project
> to have its own namespace (e.g. control_exchange to namespace topics)
> and the former makes sense where you want interop between projects (e.g.
> the keys of the RPC message envelope)

I don't expect sending these objects between projects.  It does seem
likely that we may want to move a base class and the object registry
functionality into oslo.

So, to be clear about what we're talking about, a message sent with oslo
rpc right now looks like:

{
    'oslo.version': '2.0',
    'oslo.message': {
        'method': 'remote_method',
        'version': '1.0',
        'namespace': 'whatever',
        'args': {
            'arg1': 'a',
            'arg2': 'b',
        }
        ...
    }
}

What we're talking about here is an additional key inside of the *value*
for an argument, so:

'args': {
    'arg1': {
        'nova.object_name': 'MyObject',
        'nova.object_data': { 'field1': '1' },
    },
}

so that there is a hint for the remote side to know what to use to turn
this data back into a real object.  Using the key 'oslo.object_name'
seems to make the most sense to me.  The object registry can still be
namespaced, so it could be:

'args': {
    'arg1': {
        'oslo.object_name': 'nova.MyObject',
        'oslo.object_data': { 'field1': '1' },
    },
}

I think that format would have us nicely prepared to do all of the rpc
friendly object support in oslo eventually.

I'm not completely sure how the serialization hooks without doing all of
this in oslo.

On the serialization side, there is a hook already you could use (but
you'll probably hate it).  In openstack.common.rpc.common we have:

    def serialize_msg(raw_msg):
        # NOTE(russellb) See the docstring for _RPC_ENVELOPE_VERSION for
more
        # information about this format.
        msg = {_VERSION_KEY: _RPC_ENVELOPE_VERSION,
               _MESSAGE_KEY: jsonutils.dumps(raw_msg)}

        return msg


jsonutils.dumps() will automatically call jsonutils.to_primitive() on
anything that is not a primitive type.  We could add a check in there to
see if the object has a to_primitive() method and if so, call that.

On the deserialize side, there's no hook really.  You could subclass
RpcDispatcher, override the dispatch() method and do it there, and then
let the base dispatch() do its thing after you do deserialization magic.

-- 
Russell Bryant