Nikolay, thanks for sharing this… I think that we really have a semantical ambiguity here. If we leave just “break-on” that both types of behavior have a right to exist.
I’m personally for defining that more explicitly with two separate instructions “success-on” and “error-on”. A use case for “success-on” may be, for example, checking a completion of another parallel task and if it’s completed then we can treat our task successful meaning that we already got what’s required. I know it sounds a little bit generic but still pointful for me. Renat Akhmerov @ Mirantis Inc. > On 03 Mar 2015, at 19:47, Nikolay Makhotkin <[email protected]> wrote: > > Hello, > > Recently we've found that break_on property of RetryPolicy is not working now. > > I tried to solve this problem but faced the another problem: How does > 'break_on' supposed to work? > > Will 'break_on' change the task state to ERROR or SUCCESS? > if ERROR, it means 'we interrupt all retry iterations and keep the state > which was before'. > But if SUCCESS, it means 'we interrupt all retry iterations and assume > SUCCESS state from task because we cought this condition'. > > This is ambiguous. > > There is a suggestion to use not just 'break_on' but, say, another, more > explicit properties which will delete this ambiguity. For example, > 'success_on' and 'error_on'. > > Thoughts? > > ----- > Best Regards, > Nikolay > @Mirantis Inc. > __________________________________________________________________________ > 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
