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

[Renat Akhmerov]

> 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 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  > 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
>>  
>> 
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

[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  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  
> wrote:
> 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
> > 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  
> > 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  
> >> 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: ope

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

[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 
wrote:

> 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
> > 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 
> 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 
> 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

[Renat Akhmerov]

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
> 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  
> 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  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

[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  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  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

[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  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

[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

[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

[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 > 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
?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

[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  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

[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