Yep, agree that this is a bug. We need to fix that. Would you please create a ticket at LP?
Thanks Renat Akhmerov @Nokia On 27 Apr 2018, 12:53 +0700, Vitalii Solodilov <mc...@yandex.ru>, wrote: > > 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. > Ok, then we have a bug because timeout policy doesn't force the task to fail. > It retries task. And after that, we have two running action parallel. > https://github.com/openstack/mistral/blob/master/mistral/engine/policies.py#L537 > > 27.04.2018, 07:50, "Renat Akhmerov" <renat.akhme...@gmail.com>: > > 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 <mc...@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 > > > > > > -- > Best regards, > > Vitalii Solodilov >
__________________________________________________________________________ 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
