Thanks for the pointer. I found the etherpad: http://etherpad.openstack.org/VersioningNovaRPCAPIs
Is there a blueprint that came / is coming out of that? I think the data representation is orthogonal e.g. in theory, we could even use XML schemas: PyDict --> XML --> XML Schema Validation --> Warn / Throw \-----> JSON -> Rabbit As it sounds like we are using JSON, it makes most sense to use JSON schemas. But doing so doesn't preclude us from using e.g. a binary format in future. I'd imagine that the RPC mechanism would simply select the relevant schema based on a few attributes of the dict (likely the queue & method name). So this would remain transparent to the caller. A basic RPC mechanisms might validate and warn against a JSON schema, another might use the schema to build a compact binary representation. But I think we can achieve this without changing nova. On Tue, Apr 24, 2012 at 8:39 AM, Eric Windisch <e...@cloudscaling.com>wrote: > > Actually, I think JSON schema for our message-bus messages might be a > really good idea (tm). Violations could just be warnings until we get > things locked down... maybe I should propose a blueprint? (Although I have > enough of a blueprint backlog as it is...) > > > This was discussed at the summit in (I believe) the API versioning talk. > There is a strong bias toward JSON inside RPC messages. However, this is > actually transparent to Nova as the RPC implementations do the decoding and > encoding. It is also hard to test and trigger such warnings as, as far as > Nova knows, all the interfaces pass python data types, not JSON. Some RPC > mechanisms could transparently serialize. As long as there is an > abstraction layer, it should be oblivious to the serialization and we > should not care too strongly. > > There was a patch a few weeks ago that has enforced using a common RPC > exception serializer using JSON, which I'm not sure is, or is not, a good > thing. I haven't yet updated the ZeroMQ driver to use this, but am in the > process of making these changes as I update for Folsom. > > All that said, I do intend that the ZeroMQ driver will use JSON when it > lands in Folsom. (it currently Pickles, but only because there was a bug > in Essex at one point, breaking JSON serialization) > > -- > Eric Windisch > > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp