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.


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

Reply via email to