Open Stack

On Sep 22, 2014, at 12:19 PM, Gordon Sim <gsim at 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.

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev