[openstack-dev] [oslo] ack(), reject() and requeue() support in rpc ...
eric at cloudscaling.com
Thu Aug 15 17:00:21 UTC 2013
On Wed, Aug 14, 2013 at 4:08 PM, Sandy Walsh <sandy.walsh at 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
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.
More information about the OpenStack-dev