may be not quite - please advice how it works in these cases 1) if break-on expression contains the reference to task result, like break-on: <% $.my_task.foo.bar = true %> but action returns ERROR and task payload is None (desired behavior: don’t puke, evaluate to false and don’t break)
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: break-on <% $.my_global_flag = true %> 3) a combination of the two break-on <% $.my_global_counter > $.my_task.counter %> We need functional tests for all 3 cases (may be unit tests but these cases become difficult to simulate/mock). DZ. On Apr 22, 2015, at 6:55 AM, Nikolay Makhotkin <nmakhot...@mirantis.com> wrote: > So, in this case I guess 'break-on' will work correctly now: > https://github.com/stackforge/mistral/blob/master/mistral/engine/policies.py#L295-L296 > > On Wed, Apr 22, 2015 at 2:58 PM, Renat Akhmerov <rakhme...@mirantis.com> > wrote: > Lingxian, yes, that’s basically what I suggest too. > > Renat Akhmerov > @ Mirantis Inc. > > > > > On 22 Apr 2015, at 16:03, Lingxian Kong <anlin.k...@gmail.com> wrote: > > > > Hi all, > > > > In my understanding, the meaning of the 'break-on' in 'retry' policy > > is just give an oppotunity to end the task execution earlier, i.e. we > > don't need to wait for all the iterations. I prefer that we keep the > > ERROR state, and keep it simple. > > > > On Wed, Apr 22, 2015 at 5:06 PM, Renat Akhmerov <rakhme...@mirantis.com> > > wrote: > >> 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 <nmakhot...@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-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 > >> > > > > > > > > -- > > Regards! > > ----------------------------------- > > Lingxian Kong > > > > __________________________________________________________________________ > > 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 > > > > -- > Best Regards, > Nikolay > __________________________________________________________________________ > 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