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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev