On Wed, Aug 14, 2013 at 4:08 PM, Sandy Walsh <sandy.wa...@rackspace.com> wrote: > At Eric's request in https://review.openstack.org/#/c/41979/ I'm > bringing this to the ML for feedback.
Thank you Sandy. > Currently, oslo-common rpc behaviour is to always ack() a message no > matter what. Actually, the Qemu and Kombu drivers default to this. The behavior and the expectation of the abstraction itself is different, in my opinion. The ZeroMQ driver doesn't presently support acknowledgements and they're not supported or exposed by the abstraction itself. The reason I've asked for a mailing list post is because acknowledgements aren't presently baked into the RPC abstraction/API. You're suggesting that the idea of acknowledgements leaks into the abstraction. It isn't necessarily bad, but it is significant enough I felt it warranted visibility here on the list. > Since each notification has a unique message_id, it's easy to detect > events we've seen before and .reject() them. Only assuming you have a very small number of consumers or store/lookup the seen-messages in a global state store such as memcache. That might work in the limited use-cases you intend to deploy this, but might not be appropriate at the level of a general abstraction. I've seen that features we support such as fanout() get horribly abused simply because they're available, used outside their respective edge-cases, for patterns they don't work well for. I suppose there is much to be said about giving people the leverage to shoot themselves in their own feet, but I'm interested in knowing more about how you intend to implement the rejection mechanism. I assume you intend to implement this at the consumer level within a project (i.e. Ceilometer), or is this something you intend to put into service.py? Also, fyi, I'm not actually terribly opposed to this patch. It makes some sense. I just want to make sure we don't foul up the abstraction in some way or unintentionally give developers rope they'll inevitably strangle themselves on. -- Regards, Eric Windisch _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
