<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">may be not quite - please advice how it works in these cases <div><br></div><div>1) if break-on expression contains the reference to task result, like </div><div>break-on: <% $.my_task.foo.bar = true %> </div><div>but action returns ERROR and task payload is None (desired behavior: don’t puke, evaluate to false and don’t break)</div><div><br></div><div>2) if break-on contains the value from (e.g. published variable, updated by other branch of workflow) - desired behavior - evaluate my_global_flag on every iteration: </div><div>break-on <% $.my_global_flag = true %></div><div><br></div><div>3) a combination of the two</div><div><div><div>break-on <% $.my_global_counter > $.my_task.counter %></div><div><br></div><div>We need functional tests for all 3 cases (may be unit tests but these cases become difficult to simulate/mock).</div><div><br></div><div>DZ. </div><div><br></div><div>On Apr 22, 2015, at 6:55 AM, Nikolay Makhotkin <<a href="mailto:nmakhotkin@mirantis.com">nmakhotkin@mirantis.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">So, in this case I guess 'break-on' will work correctly now: <a href="https://github.com/stackforge/mistral/blob/master/mistral/engine/policies.py#L295-L296">https://github.com/stackforge/mistral/blob/master/mistral/engine/policies.py#L295-L296</a></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 22, 2015 at 2:58 PM, Renat Akhmerov <span dir="ltr"><<a href="mailto:rakhmerov@mirantis.com" target="_blank">rakhmerov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Lingxian, yes, that’s basically what I suggest too.<br>
<span class="im HOEnZb"><br>
Renat Akhmerov<br>
@ Mirantis Inc.<br>
<br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">> On 22 Apr 2015, at 16:03, Lingxian Kong <<a href="mailto:anlin.kong@gmail.com">anlin.kong@gmail.com</a>> wrote:<br>
><br>
> Hi all,<br>
><br>
> In my understanding, the meaning of the 'break-on' in 'retry' policy<br>
> is just give an oppotunity to end the task execution earlier, i.e. we<br>
> don't need to wait for all the iterations. I prefer that we keep the<br>
> ERROR state, and keep it simple.<br>
><br>
> On Wed, Apr 22, 2015 at 5:06 PM, Renat Akhmerov <<a href="mailto:rakhmerov@mirantis.com">rakhmerov@mirantis.com</a>> wrote:<br>
>> Ok, after all thinking my suggestion is to leave "break-on” but clarify its<br>
>> semantics and behavior a little bit as follow:<br>
>><br>
>> As Dmitri wrote before “success-on” and “error-on” may be easily confused<br>
>> with “on-success” and “on-error”.<br>
>> “retry" policy loop may only stop if:<br>
>><br>
>> Task action/workflow completed successfully (no need to retry anymore). This<br>
>> case has nothing to do with “break-on”.<br>
>> Task action/workflow failed and some condition (“break-on”) evaluates to<br>
>> True. So in this case I don’t think we need to give a user opportunity to<br>
>> change semantics of task behavior and be able to say “although task<br>
>> action/workflow failed I want this task to finish with success”. IMO, it may<br>
>> be 1) confusing 2) error-prone 3) complicating our understanding of how<br>
>> workflow works. In other works, I’m now against of this behavior and I think<br>
>> that success/error of action/workflow should exactly match to success/error<br>
>> of task.<br>
>><br>
>> Based on the previous thoughts evaluation of “break-on” condition should<br>
>> work against task inbound context that doesn’t contain a task result itself<br>
>> (because the action failed) but may include results of other tasks completed<br>
>> in parallel branches. The general use case for this is to “stop waiting for<br>
>> something if we see that fundamental requirements for that are not met”.<br>
>><br>
>><br>
>> Thoughts?<br>
>><br>
>> Renat Akhmerov<br>
>> @ Mirantis Inc.<br>
>><br>
>><br>
>><br>
>> On 21 Apr 2015, at 14:11, Nikolay Makhotkin <<a href="mailto:nmakhotkin@mirantis.com">nmakhotkin@mirantis.com</a>> wrote:<br>
>><br>
>> Any more suggestions/thoughts here? Dmitri?<br>
>><br>
>> More words: succeed-on / fail-on, success-expr / error-expr.<br>
>><br>
>> --<br>
>> Best Regards,<br>
>> Nikolay<br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> Regards!<br>
> -----------------------------------<br>
> Lingxian Kong<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><font size="2">Best Regards,</font></div><div><font size="2">Nikolay</font></div></div></div>
</div>
__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></blockquote></div><br></div></body></html>