openstack team mailing list archive

[Eric Windisch <eric@xxxxxxxxxxxxxxxx>]

I've heard a few people mention pulling messages off the queue, or communicating via RPC outside of the project, or outside of Python. In theory, this sounds nice, but the RPC implementations are strictly making sure that A can execute calls on target B and that responses get back to A.

This has little to do with message queues, other than that message queues are optionally supported. You shouldn't be peeking behind that curtain. This is specific to each RPC mechanism and enforcing something this early might be more problematic than you expect.

I think that in the Folsom time frame, if not beyond, we should suggest a best practice of using the OpenStack RPC modules if you intend to communicate with Nova services. They're moving into OpenStack common, so this will become more friendly to use. It will require Python, but I don't see a reasonable alternative at the moment.

Additionally, each RPC driver can provide a guide to complying with their protocol, which extends beyond simply the transport (i.e. AMQP or ZeroMQ). This might be harder than it sounds and might vary between, or even within, releases.

--  
Eric Windisch


On Wednesday, April 25, 2012 at 1:24 PM, Joshua Harlow wrote:

> Re: [Openstack] Canonical AWSOME So if what u are talking about is anything RPC/MQ based, then I would say those are not internal API’s.
>  
> Once a RPC/MQ mechanism is introduced they don’t really become internal API’s anymore (if we are talking about the same API’s, haha).
>  
> Since other stuff can be reading those messages on the MQ its very useful to have a schema to know exactly what to read :-)
>  
> On 4/24/12 11:46 AM, "Russell Bryant" <rbryant@xxxxxxxxxx> wrote:
>  
> > On 04/24/2012 01:25 PM, Joshua Harlow wrote:
> > > I’m more in favor of just having a schema, I don’t care if that compiles
> > > to protocol buffers, json, NEWAWESOMEhipsterMSGFORMAT.
> > >
> > > That schema will force people to think a little more when they add
> > > messages, and it will automatically document the messages that are being
> > > sent around.
> > >
> > > That’s a big win I think and is a step to getting those schemas
> > > versioned...
> >  
> > I'm not sure a schema is really necessary aside from the Python classes
> > themselves.  They're internal APIs, so they shouldn't be used from
> > outside of Nova.  A schema would be useful if we had to define the
> > interfaces in some language neutral-format, but I don't think that
> > really matters here.
> >  
> > I'm going to work on a proposal / prototype for how we can handle
> > versioning, though.  The big goal here is making sure that we can
> > maintain compatibility with the previous release.
> >  
> > --
> > Russell Bryant
> >  
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >  
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx (mailto:openstack@xxxxxxxxxxxxxxxxxxx)
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>  
>