[openstack-dev] [mistral] Break_on in Retry policy
Dmitri Zimine
dzimine at stackstorm.com
Wed Apr 22 14:46:45 UTC 2015
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 <nmakhotkin at 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 <rakhmerov at 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.kong at 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 <rakhmerov at 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 <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
> >>
> >>
> >>
> >> __________________________________________________________________________
> >> 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
> >>
> >
> >
> >
> > --
> > Regards!
> > -----------------------------------
> > Lingxian Kong
> >
> > __________________________________________________________________________
> > 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
>
>
> __________________________________________________________________________
> 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
>
>
>
> --
> 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/ca44ed4e/attachment.html>
More information about the OpenStack-dev
mailing list