mirror of
https://github.com/apache/cloudstack
synced 2026-08-08 15:48:29 +00:00
3c68b9f850
The things is, VR would take time to execute the commands, say it would need time t1(which is greater than 0). And the interval between parallel deployment is t2(which can be almost 0). In any case, VR need to handle commands in sequence internally, so if t1 > t2, then the new task in the VR would wait longer and longer to execute, then some commands result in timeout ultimately. No matter how long the timeout is, if there are enough big number of queued task for VR, the last ones can timeout. Currently VR has a robust mechanism to sequence the jobs internal and I confirmed in this case, it works well. But there is no way to fix this issue if VR is already 100% load at all time. Probably we can improve the speed of VR internal executing, but seems the ultimate answer is: set execute.in.sequence.network.element.commands to true. VR doesn’t know how long it would take for mgmt. server to timeout, only mgmt. server knows that. By setting sequence execution in VR to "true", mgmt server would handle the commands in a queue, make sure that VR won't be overload and report unexpected failure just because it's overload. |
||
|---|---|---|
| .. | ||
| account | ||
| acl | ||
| agent/manager | ||
| alert | ||
| api | ||
| async | ||
| capacity | ||
| configuration | ||
| consoleproxy | ||
| dc | ||
| deploy | ||
| event | ||
| ha | ||
| hypervisor | ||
| keystore | ||
| metadata | ||
| network | ||
| projects | ||
| resource | ||
| resourcelimit | ||
| secstorage | ||
| server | ||
| servlet | ||
| storage | ||
| tags | ||
| template | ||
| test | ||
| usage | ||
| user | ||
| uuididentity | ||
| vm | ||
