On 09/22/2014 09:25 PM, Doug Hellmann wrote: > > On Sep 22, 2014, at 12:19 PM, Gordon Sim <g...@redhat.com> wrote: > >> On 09/22/2014 03:40 PM, Geoff O'Callaghan wrote: >>> That being said I'm not sure why a well constructed zaqar with an rpc >>> interface couldn't meet the requirements of oslo.messsaging and much more. >> >> What Zaqar is today and what it might become may of course be different >> things but as it stands today, Zaqar relies on polling which in my opinion >> is not a natural fit for RPC[1]. Though using an intermediary for >> routing/addressing can be of benefit, store and forward is not necessary and >> in my opinion even gets in the way[2]. >> >> Notifications on the other hand can benefit from store and forward and may >> be less latency sensitive, alleviating the polling concerns. >> >> One of the use cases I've heard cited for Zaqar is as an inbox for recording >> certain sets of relevant events sent out by other open stack services. In my >> opinion using oslo.messaging's notification API on the openstack service >> side of this would seem - to me at least - quite sensible, even if the >> events are then stored in (or forwarded to) Zaqar and accessed by users >> through Zaqar's own protocol. > > I agree that the notification features of oslo.messaging are more likely to > be useful through Zaqar than the RPC API. Our internal notifications may > include information we wouldn’t want to leak outside of a cloud, but a > notification driver for oslo.messaging that talked to Zaqar and took into > account tenant-based addressing in some way might make a lot of sense. >
I won't get into much detail on this right now but I agree and it was discussed already - at the Juno summit, I believe. Thanks, Flavio > Doug > >> >> ---- >> >> [1] The latency of an RPC call as perceived by the client is going to depend >> heavily on the polling frequency; to get lower latency, you'll need to pool >> more frequently both on the server and on the client. However polling more >> frequently results in increased load even when no requests are being made. >> >> [2] I am of the view that reliable RPC is best handled by replaying the >> request from the client when needed, rather than trying to make the request >> and reply messages durably recorded, replicated and reliably delivered. >> Doing so is more scalable and simpler. An end-to-end acknowledgement for the >> request (rather than a broker taking responsibility and acknowledging the >> request independent of delivery status) makes it easier to detect failures >> and trigger a resend. >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- @flaper87 Flavio Percoco _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
