Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150304/4b77f1a0/attachment.html>