Re: [openstack-dev] [mistral] Break_on in Retry policy

2015-04-23 Thread Renat Akhmerov

 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


Re: [openstack-dev] [mistral] Break_on in Retry policy

2015-04-22 Thread Nikolay Makhotkin
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


Re: [openstack-dev] [mistral] Break_on in Retry policy

2015-04-22 Thread Dmitri Zimine
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


Re: [openstack-dev] [mistral] Break_on in Retry policy

2015-04-22 Thread Lingxian Kong
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


Re: [openstack-dev] [mistral] Break_on in Retry policy

2015-04-22 Thread 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 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


Re: [openstack-dev] [mistral] Break_on in Retry policy

2015-04-22 Thread Renat Akhmerov
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


Re: [openstack-dev] [mistral] Break_on in Retry policy

2015-04-21 Thread Nikolay Makhotkin
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


Re: [openstack-dev] [mistral] Break_on in Retry policy

2015-03-04 Thread Nikolay Makhotkin
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


[openstack-dev] [mistral] Break_on in Retry policy

2015-03-04 Thread Thomas Hsiao
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


Re: [openstack-dev] [mistral] Break_on in Retry policy

2015-03-04 Thread Renat Akhmerov
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


[openstack-dev] [mistral] Break_on in Retry policy

2015-03-03 Thread Nikolay Makhotkin
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