Lingxian, yes, that’s basically what I suggest too. Renat Akhmerov @ Mirantis Inc.
> On 22 Apr 2015, at 16:03, Lingxian Kong <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Regards! > ----------------------------------- > Lingxian Kong > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
