Open Stack

Ok, after all thinking my suggestion is to leave "break-on” but clarify its semantics and behavior a little bit as follow:
As Dmitri wrote before “success-on” and “error-on” may be easily confused with “on-success” and “on-error”.
“retry" policy loop may only stop if:
Task action/workflow completed successfully (no need to retry anymore). This case has nothing to do with “break-on”.
Task action/workflow failed and some condition (“break-on”) evaluates to True. So in this case I don’t think we need to give a user opportunity to change semantics of task behavior and be able to say “although task action/workflow failed I want this task to finish with success”. IMO, it may be 1) confusing 2) error-prone 3) complicating our understanding of how workflow works. In other works, I’m now against of this behavior and I think that success/error of action/workflow should exactly match to success/error of task.
Based on the previous thoughts evaluation of “break-on” condition should work against task inbound context that doesn’t contain a task result itself (because the action failed) but may include results of other tasks completed in parallel branches. The general use case for this is to “stop waiting for something if we see that fundamental requirements for that are not met”.

Thoughts?

Renat Akhmerov
@ Mirantis Inc.



> On 21 Apr 2015, at 14:11, Nikolay Makhotkin <nmakhotkin at mirantis.com> wrote:
> 
> Any more suggestions/thoughts here? Dmitri? 
> 
> More words: succeed-on / fail-on, success-expr / error-expr.
> 
> -- 
> Best Regards,
> Nikolay
> __________________________________________________________________________
> 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/20150422/84330797/attachment.html>