Re: [openstack-dev] ​ [mistral] timeout and retry

2018-04-27 Thread Vitalii Solodilov 
Thanks for confirmation.Ticket https://bugs.launchpad.net/mistral/+bug/1767352I will try to fix it. 27.04.2018, 12:02, "Renat Akhmerov" :Yep, agree that this is a bug. We need to fix that. Would you please create a ticket at LP?ThanksRenat Akhmerov@NokiaOn 27 Apr 2018, 12:53 +0700, Vitalii Solodilov , 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" :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.ThanksRenat Akhmerov@NokiaOn 24 Apr 2018, 05:00 +0700, Vitalii Solodilov , 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/hhm0eHExample: 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_376083Even 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/fe5tzHIt 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

Re: [openstack-dev] ​[openstack-dev] [mistral] timeout and retry

2018-04-27 Thread Renat Akhmerov 
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 , 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" :
> > 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 , 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

Re: [openstack-dev] ​ [mistral] timeout and retry

2018-04-26 Thread Vitalii Solodilov 
> 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" :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.ThanksRenat Akhmerov@NokiaOn 24 Apr 2018, 05:00 +0700, Vitalii Solodilov , 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/hhm0eHExample: 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_376083Even 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/fe5tzHIt 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

Re: [openstack-dev] ​[openstack-dev] [mistral] timeout and retry

2018-04-26 Thread Renat Akhmerov 
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 , 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
>
__
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

[openstack-dev] ​ [mistral] timeout and retry

2018-04-23 Thread Vitalii Solodilov 
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


__
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