Open Stack

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.