Open Stack

Lingxian, yes, that’s basically what I suggest too.

Renat Akhmerov
@ Mirantis Inc.



> On 22 Apr 2015, at 16:03, Lingxian Kong <anlin.kong at 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 <rakhmerov at 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 <nmakhotkin at 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-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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev