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 break)
I’m a little confused now. I remember we discussed it with you already but I’m
just trying to see in what cases we may get action result (= task result) but
have action in ERROR state. The only case that I see is when we use
“with-items” and part of actions completed successfully by the time that some
action (iteration of “with-items”) failed. Then in $.my_task we would be able
to provide a partial (incomplete) result consisting of those successful action
results. It’s not how it’s supposed to work now though. If at least one action
fails then all successful iterations get invalidated too.
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 %
Yes, that would be cool to do. The implementation I think is not going to be
easy though..
3) a combination of the two
break-on % $.my_global_counter $.my_task.counter %
Yes. We need to clarify 1)
On Apr 22, 2015, at 6:55 AM, Nikolay Makhotkin nmakhot...@mirantis.com
mailto: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
https://github.com/stackforge/mistral/blob/master/mistral/engine/policies.py#L295-L296
Yes, you’re right. It seems like it works now as I described.
Renat Akhmerov
@ Mirantis Inc.
__
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

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

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

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

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

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

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:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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 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 “success-on”
may be, for example, checking a completion of another parallel task
and if it’s completed then we can treat our task successful meaning
that we already got what’s required. I know it sounds a little bit
generic but still pointful for me.
Renat Akhmerov
@ Mirantis Inc.
* On 03 Mar 2015, at 19:47, Nikolay Makhotkin nmakhotkin at mirantis.com
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev wrote:
* * 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 iterations and keep the
state which was before'.
** But if SUCCESS, it means 'we interrupt all retry iterations and
assume SUCCESS state from task because we cought this condition'.
* * This is ambiguous.
* * There is a suggestion to use not just 'break_on' but, say,
another, more explicit properties which will delete this ambiguity.
For example, 'success_on' and 'error_on'.
* * Thoughts?
* * -
** Best Regards,
** Nikolay
** @Mirantis Inc.
** __
** OpenStack Development Mailing List (not for usage questions)
** Unsubscribe: OpenStack-dev-request at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev?subject:unsubscribe
** http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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

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 “success-on” may be, for example,
checking a completion of another parallel task and if it’s completed then we
can treat our task successful meaning that we already got what’s required. I
know it sounds a little bit generic but still pointful for me.
Renat Akhmerov
@ Mirantis Inc.
On 03 Mar 2015, at 19:47, Nikolay Makhotkin nmakhot...@mirantis.com wrote:
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 iterations and keep the state
which was before'.
But if SUCCESS, it means 'we interrupt all retry iterations and assume
SUCCESS state from task because we cought this condition'.
This is ambiguous.
There is a suggestion to use not just 'break_on' but, say, another, more
explicit properties which will delete this ambiguity. For example,
'success_on' and 'error_on'.
Thoughts?
-
Best Regards,
Nikolay
@Mirantis Inc.
__
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

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 iterations and keep the state
which was before'.
But if SUCCESS, it means 'we interrupt all retry iterations and assume
SUCCESS state from task because we cought this condition'.
This is ambiguous.
There is a suggestion to use not just 'break_on' but, say, another, more
explicit properties which will delete this ambiguity. For example,
'success_on' and 'error_on'.
Thoughts?
-
Best Regards,
Nikolay
@Mirantis Inc.
__
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