[
https://issues.apache.org/jira/browse/CLOUDSTACK-9319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15517493#comment-15517493
]
ASF GitHub Bot commented on CLOUDSTACK-9319:
--------------------------------------------
Github user insom commented on the issue:
https://github.com/apache/cloudstack/pull/1451
@ustcweizhou A _side effect_ of this PR is setting the minimal timeout to
120, but that's what the original code intended - except that because of not
passing through the timeout to `applyConfigToVR` it wasn't taking effect.
What this PR really does is make the code work as intended. I'm up for
improvements but if this is blocking upgrades (and at least iWeb and one other
CloudStack user were hit by it) seems like merging this and _then_ moving it to
a per-host setting would be a good idea?
> 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)
