Open Stack

On 05/30/2013 04:24 PM, Doug Hellmann wrote:
>
>
>
> On Wed, May 29, 2013 at 11:03 AM, Tomas Sedovic <tsedovic at redhat.com
> <mailto:tsedovic at redhat.com>> wrote:
>
>     On 05/28/2013 08:22 PM, Gabriel Hurley wrote:
>
>         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 <http://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.
>
>     What should be the next steps here (sorry, I'm not too familiar with
>     everything yet)?
>
>     I'll fix the patches to pass the tests (there are some requirements
>     issues and possibly other stuff, too).
>
>     I can certainly help with oslo.notify, but the blueprint is already
>     assigned and scheduled for a later milestone (h3) than the
>     realtime-communication one (h2).
>
>
> I suspect that's for the new API, rather than the existing library. You
> should probably go ahead and work with the API we have now, and
> anticipate moving to the new version during the I cycle.
>
> Doug

Ah, okay. Thanks!

>
>
>     I suppose we want to have that working before we call the
>     realtime-communication blueprint done. Anything else comes to your mind?
>
>     Tomas
>
>
>         Thanks!
>
>         -Gabriel
>
>         *From:*Doug Hellmann [mailto:doug.hellmann at __dreamhost.com
>         <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>
>         <mailto: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>>
>           > > <mailto: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
>         <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> <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> <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>
>         <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>
>              <mailto:OpenStack-dev at lists.__openstack.org
>         <mailto:OpenStack-dev at lists.openstack.org>>
>         http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
>         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
>         _________________________________________________
>         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
>         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>     _________________________________________________
>     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 <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>