Thanks for confirmation.
Ticket https://bugs.launchpad.net/mistral/+bug/1767352
I will try to fix it.
I will try to fix it.
27.04.2018, 12:02, "Renat Akhmerov" <renat.akhme...@gmail.com>:
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.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
--
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
