Crew, as discussed in the last team meeting, I have updated the API v1.1 spec<https://wiki.openstack.org/wiki/Marconi/specs/api/v1.1> to remove the ability to get one or more messages by ID. This was done to remove unnecessary complexity from the API, and to make it easier to support different types of message store backends.
However, this now leaves us with asymmetric semantics. On the one hand, we do not allow retrieving messages by ID, but we still support deleting them by ID. It seems to me that deleting a message only makes sense in the context of a claim or pop operation. In the case of a pop, the message is already deleted by the time the client receives it, so I don’t see a need for including a message ID in the response. When claiming a batch of messages, however, the client still needs some way to delete each message after processing it. In this case, we either need to allow the client to delete an entire batch of messages using the claim ID, or we still need individual message IDs (hrefs) that can be DELETEd. Deleting a batch of messages can be accomplished in V1.0 using “delete multiple messages by ID”. Regardless of how it is done, I’ve been wondering if it is actually an anti-pattern; if a worker crashes after processing N messages, but before deleting those same N messages, the system is left with several messages that another worker will pick up and potentially reprocess, although the work has already been done. If the work is idempotent, this isn’t a big deal. Otherwise, the client will have to have a way to check whether a message has already been processed, ignoring it if it has. But whether it is 1 message or N messages left in a bad state by the first worker, the other worker has to follow the same logic, so perhaps it would make sense after all to simply allow deleting entire batches of claimed messages by claim ID, and not worrying about providing individual message hrefs/IDs for deletion. With all this in mind, I’m starting to wonder if I should revert my changes to the spec, and wait to address these changes in the v2.0 API, since it seems that to do this right, we need to make some changes that are anything but “minor” (for a minor release). What does everyone think? Should we postpone this work to 2.0? —Kurt
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
