[openstack-dev] =?utf-8?Q?=E2=80=8B=5Bopenstack-dev=5D_?=[mistral] timeout and retry

Renat Akhmerov renat.akhmerov at gmail.com
Fri Apr 27 04:45:22 UTC 2018


Hi,

I don’t clearly understand the problem you’re trying to point to.

IMO, when using these two policies at the same time ‘timeout’ policy should have higher priority. No matter at what stage the task is, but if it’s still in RUNNING state or FAILED but we know that retry policy still didn’t use all attempts then the ‘timeout’ policy should force the task to fail. If it’s the second case when it’s FAILED but the retry policy is still in play then we need to leave some ‘force’ marker in the task state to make sure that there’s no need to retry it further.

Thanks

Renat Akhmerov
@Nokia

On 24 Apr 2018, 05:00 +0700, Vitalii Solodilov <mcdkr at yandex.ru>, wrote:
> Hi Renat, Can you explain me and Dougal how timeout policy should work with retry policy?
>
> I guess there is bug right now.
> The behaviour is something like this https://ibb.co/hhm0eH
> Example: https://review.openstack.org/#/c/563759/
> Logs: http://logs.openstack.org/59/563759/1/check/openstack-tox-py27/6f38808/job-output.txt.gz#_2018-04-23_20_54_55_376083
> Even we will fix this bug and after task timeout we will not retry task. I don't understand which problem is decided by this timeout and retry.
> Other problem. What about task retry? I mean using mistral api. The problem is that timeout delayed calls was not created.
>
> IMHO the combination of these policies should work like this https://ibb.co/fe5tzH
> It is not a timeout per action because when task retry it move to some complete state and then back to RUNNING state. And it will work fine with with-items policy.
> The main advantage is executor and rabbitmq HA. I can specify small timeout if executor will die the task retried by timeout and create new action.
> The second is predictable behaviour. When I specify timeout: 10 and retry.count: 5 I know that will be create maximum 5 action before SUCCESS state and every action will be executes no longer than 10 seconds.
>
> --
> Best regards,
>
> Vitalii Solodilov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180427/aa562075/attachment.html>


More information about the OpenStack-dev mailing list