[openstack-dev] Oslo messaging API design

Mark McLoughlin markmc at redhat.com
Mon May 13 15:02:10 UTC 2013


Hey Doug,

On Mon, 2013-05-13 at 10:43 -0400, Doug Hellmann wrote:
> 
> 
> 
> On Sat, May 11, 2013 at 1:07 PM, Mark McLoughlin <markmc at redhat.com> wrote:
>         On Mon, 2013-04-29 at 11:12 +0100, Mark McLoughlin wrote:
>         > Hey
>         >
>         > I've been working on gathering requirements and design ideas for a
>         > re-design of Oslo's RPC and notifications API. The goals are:
>         >
>         >   1) A simple and easy to understand RPC abstraction which enables
>         >      all of the intra project communication patterns we need for
>         >      OpenStack
>         >
>         >   2) It should be possible to implement the RPC abstraction using a
>         >      variety of messaging transports, not just AMQP or AMQP-like
>         >
>         >   3) It should be a stable API with plenty of room for backwards
>         >      compatible evolution in the future so that we can release it as a
>         >      standalone library
>         >
>         > Here's what I have so far:
>         >
>         >   https://wiki.openstack.org/wiki/Oslo/Messaging
>         
>         
>         Just a quick status update. We're using this etherpad to coordinate:
>         
>           https://etherpad.openstack.org/HavanaOsloMessaging
>         
>         and this branch:
>         
>           https://github.com/markmc/oslo-incubator/commits/messaging
>         
>         At this point, we've got a pretty solid API design, a working fake
>         driver and some simple test code.
> 
> 
> Have you given any thought to how the MessageHandlingServer can listen
> on more than one target? That's an important use case for ceilometer,
> which I didn't address in my earlier changes.
> 
> 
> Do we need to support different transports (and drivers), or just
> multiple targets?

I guess I was thinking you'd just create multiple servers, but you
probably really want a single executor and dispatcher pair with multiple
listeners.

Would something like this work?

    def start(self):
        if self._executor is not None:
            return
        self._executor = self._executor_cls(self.conf, self.dispatcher)
        self.listen(self.transport, self.target)
	self._executor.start()

    def listen(self, transport, target):
        self._executor.add_listener(transport._listen(target))

Cheers,
Mark.




More information about the OpenStack-dev mailing list