I haven't spent much time on this, so the answers below are a first approximation based on a quick visual inspection (e.g. subject to change when I get a chance to hack on some code). On 4/21/16 12:10 PM, Salvatore Orlando wrote: > Can you share more details on the "few things we need" that > retrying is lacking? (a) Some of our existing code uses a 'stepping' scheme (fist N attempts with timeout T, next M attempts with timeout U, etc.). For example [1]. This could also be tackled using chaining. (b) It doesn't appear retrying supports capping (ceiling) exponential sleep times as we do in [2]. > Do you think oslo_messaging would be a good target? Or do you think it > should go somewhere else? My initial thought was to implement it as a subclass of oslo_messaging's RPCClient [3] with a nice way for consumers to configure the backoff/retry magic. If consumers want a backing off client, then they use the new subclass. [1] https://github.com/openstack/nova/blob/master/nova/conductor/api.py#L147 [2] https://review.openstack.org/#/c/280595/ [3] https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/rpc/client.py#L208