On 22 Apr 2015, at 20:46, Dmitri Zimine dzim...@stackstorm.com 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
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
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
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
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
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:
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:
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
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
11 matches
Mail list logo
