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 <nmakhot...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to