> On 22 Apr 2015, at 20:46, Dmitri Zimine wrote:
>
> 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)
I’m a
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
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
wrote:
> Lingxian, yes, that’s basically what I suggest too.
>
> Renat Akhmerov
> @ Mirantis Inc.
>
Lingxian, yes, that’s basically what I suggest too.
Renat Akhmerov
@ Mirantis Inc.
> On 22 Apr 2015, at 16:03, Lingxian Kong 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
> d
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
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 complet
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-req
Ok, we will proceed with error-on and success-on.
Thanks for the reply!
--
Best Regards,
Nikolay
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
Hi,
I like the idea of explicit checks by success-on and error-on:
success-on to break retry and get SUCCESS state.
error-on to break retry but get ERROR state.
A single break-on seems confusing to me too.
Regards,
Thomas Hsiao
HP Cloud
Nikolay, thanks for sharing this…
I think that we re
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 “
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 iteration
11 matches
Mail list logo