Open Stack

I agree with Doug (big surprise since we've discussed this before) on both points. Everything up to the dispatch mechanism can be shared but the dispatcher itself (which probably has some logic for transforming and filtering messages) is going to be too specialized for each consumer. For Horizon it makes the most sense to run a very lightweight process for consuming messages and pushing them out via socket.io. As far as I'm aware, the work happening in Oslo will support these ends nicely.

I still need to try running the PoC that Tomas has presented here, but it seems like it's got the right ideas. It's very much in line with what the Horizon core devs discussed at the last two summits. Work on this was slated for later in the H release, but this looks like a great kickstart for it.

Thanks!


-          Gabriel

From: Doug Hellmann [mailto:doug.hellmann at dreamhost.com]
Sent: Tuesday, May 28, 2013 9:35 AM
To: Mark McLoughlin; OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Horizon] Realtime push-based communication PoC



On Tue, May 28, 2013 at 4:22 AM, Mark McLoughlin <markmc at redhat.com<mailto:markmc at redhat.com>> wrote:
Hey Tomas,

On Tue, 2013-05-28 at 09:29 +0200, Tomas Sedovic wrote:
> On 05/24/2013 08:36 PM, Doug Hellmann wrote:
> >
> >
> >
> > On Fri, May 24, 2013 at 12:39 PM, Tomas Sedovic <tsedovic at redhat.com<mailto:tsedovic at redhat.com>
> > <mailto:tsedovic at redhat.com<mailto:tsedovic at redhat.com>>> wrote:
...
> >     I wonder if we could leverage Ceilometer here since it already
> >     listens in on the message bus. Could it be configured to send
> >     interesting information to Horizon (as opposed to being polled for it)?
> >
> >
> > This really feels like a different use case that what ceilometer is made
> > for. Gabriel and I talked at the grizzly summit about the code we have
> > in ceilometer for listening to notifications, and we agreed to try to
> > put that in oslo somewhere to make it easier to create a similar
> > listening service in horizon that redirects the notifications to the
> > browser(s). I haven't had a chance to do that. If you want to tackle it,
> > I can help figure out which bits are interesting/useful.
>
> Thanks, I thought that might be the case but I didn't know enough to be
> sure.
>
> Putting the bits to oslo sounds like a neat idea.
The notifications listening API is basically the last API design task
for the oslo messaging API:
https://wiki.openstack.org/wiki/Oslo/Messaging#Handling_Notifications

Part of the justification for moving the dispatching logic into its own class (and out of the RPC client) was to make listening to notifications easier. The server, transport, target, and driver should all be reusable up to the point of the actual dispatcher object. I'm not even sure we need a special notification dispatcher in Oslo, since the consumers are likely to have different dispatching rules (in ceilometer we may pass the same notification to several plugins, but in horizon they will simply want to move the notification to the socket.io<http://socket.io> output stream).



> I'm certainly willing
> to look into it, but I'd like to get some feedback on this first.
I guess the question comes down to whether Horizon itself should be
listening on the message bus or whether we have some other agent consume
notifications and send them to Horizon via socket.io<http://socket.io>?

A separate agent makes more sense. It will be easier to configure whether or not it should be used at all, and (based on my limited understanding of socket.io<http://socket.io>) it should not be running behind apache.

Doug


Cheers,
Mark.


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130528/b02c240c/attachment.html>