cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-9319) Timeout is not passed to virtual router operations consistently
Date Sat, 26 Mar 2016 00:21:25 GMT


ASF GitHub Bot commented on CLOUDSTACK-9319:

Github user alexandrelimassantana commented on the pull request:
    @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:
    if (timeout < 120) {
        timeout = 120;
    if (timeout < VRScripts.DEFAULT_EXECUTEINVR_TIMEOUT) {
        timeout = VRScripts.DEFAULT_EXECUTEINVR_TIMEOUT;

> Timeout is not passed to virtual router operations consistently
> ---------------------------------------------------------------
>                 Key: CLOUDSTACK-9319
>                 URL:
>             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

View raw message