Open Stack

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.

----

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