[openstack-dev] Oslo messaging API design

Doug Hellmann doug.hellmann at dreamhost.com
Mon May 13 15:27:04 UTC 2013


On Mon, May 13, 2013 at 11:02 AM, Mark McLoughlin <markmc at redhat.com> wrote:

> 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))
>

I am worried there might be a case where the executor will have a hard time
adding a listener after it has been started. How would the blocking
executor do that, for example?

Doug


>
> Cheers,
> Mark.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130513/ebd9b0d9/attachment.html>


More information about the OpenStack-dev mailing list