Boden Russell wrote:
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.
This might be harder in retrying, but I think I can help u make
something that will work, since retrying has a way to provide a custom
delay function.
(b) It doesn't appear retrying supports capping (ceiling) exponential
sleep times as we do in [2].
https://github.com/rholder/retrying/blob/master/retrying.py#L65
'wait_exponential_max'?
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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
