On 06/12/2015 09:41 PM, Alec Hothan (ahothan) wrote:
One long standing issue I can see is the fact that the oslo messaging API documentation is sorely lacking details on critical areas such as API behavior during fault conditions, load conditions and scale conditions.
I very much agree, particularly on the contract/expectations in the face of different failure conditions. Even for those who are critical of the pluggability of oslo.messaging, greater clarity here would be of benefit.
As I understand it, the intention is that RPC calls are invoked on a server at-most-once, meaning that in the event of any failure, the call will only be retried by the olso.messaging layer if it believes it can ensure the invocation is not made twice.
If that is correct, stating so explicitly and prominently would be worthwhile. The expectation for services using the API would then be to decide on any retry themselves. An idempotent call could retry for a configured number of attempts perhaps. A non-idempotent call might be able to check the result via some other call and decide based on that whether to retry. Giving up would then be a last resort. This would help increase robustness of the system overall.
Again if the assumption of at-most-once is correct, and explicitly stated, the design of the code can be reviewed to ensure it logically meets that guarantee and of course it can also be explicitly tested for in stress tests at the oslo.messaging level, ensuring there are no unintended duplicate invocations. An explicit contract also allows different approaches to be assessed and compared.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev