[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15212650#comment-15212650
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9319:
--------------------------------------------

Github user alexandrelimassantana commented on the pull request:

    https://github.com/apache/cloudstack/pull/1451#issuecomment-201610435
  
    @insom with this changes there is still one place where the applyConfigToVR 
is not provided with this timeout parameter (line 183, same class). This 
function is actually called only in those 2 places. If it comes to a state 
where you will always supply the timeout, remove the one which doesn't require 
you to.
    
    Also, if you plan to always supply the timeout, a change into lines 378 and 
379 would provide more coersion:
    ```Java
    if (timeout < 120) {
        timeout = 120;
    }
    ```
    into:
    
    ```Java
    if (timeout < VRScripts.DEFAULT_EXECUTEINVR_TIMEOUT) {
        timeout = VRScripts.DEFAULT_EXECUTEINVR_TIMEOUT;
    }
    ```


> Timeout is not passed to virtual router operations consistently
> ---------------------------------------------------------------
>
>                 Key: CLOUDSTACK-9319
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9319
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>          Components: Virtual Router
>    Affects Versions: 4.8.0
>         Environment: KVM + Ceph cloud, Ubuntu hosts.
>            Reporter: Aaron Brady
>            Priority: Trivial
>
> The timeout parameter is not passed down to `applyConfigToVR` inside 
> `VirtualRoutingResource` in all cases.
> This timeout is worked out as 3 seconds per command or 120 seconds (whichever 
> is larger), but because it's not passed to the first invocation, the default 
> (120 seconds, DEFAULT_EXECUTEINVR_TIMEOUT) is used.
> In a recent upgrade of our Virtual Routers, the timeout was being hit and 
> increasing `router.aggregation.command.each.timeout` had no effect. I built a 
> custom 4.8 agent with the timeout increased to allow the upgrade to continue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to