Open Stack

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