[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