cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-6047) Make Virtual Router to aggregate execution of commands
Date Sat, 19 Apr 2014 06:36:15 GMT


ASF subversion and git services commented on CLOUDSTACK-6047:

Commit 3578c7137f42fdcaadad9b263e18921e2fa094da in cloudstack's branch refs/heads/4.4 from
[;h=3578c71 ]

CLOUDSTACK-6047: Make aggregation command timeout configurable

In case some environments has different performance or we found some commands
would took too long to execute, one global configuration item is introduced to
specify "time out in seconds per one command in aggregation commands".

By default it's 3 seconds. If admin feel it's too long, it can be adjust to as
low as 1 seconds, which runs still well in my machine.

> Make Virtual Router to aggregate execution of commands
> ------------------------------------------------------
>                 Key: CLOUDSTACK-6047
>                 URL:
>             Project: CloudStack
>          Issue Type: Improvement
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Network Controller, Virtual Router
>            Reporter: Sheng Yang
>            Assignee: Sheng Yang
>            Priority: Blocker
>             Fix For: 4.4.0
> Currently VR has an scalability issue during the large deployment. Everytime when VR
need to be re-create or reboot, CloudStack would send lots of programming commands to it.
VR would treat them as individual commands then execute them. In large deployment, it would
take tens of minutes or even hours to complete all the necessary updates, like setup DHCP
and programming firewall.
> For example, in the past, everytime we setup DHCP in VR, we need to restart dnsmasq service
for every programming, which is very time consuming. Though we've introduced a way to reload
without restart dnsmasq, but the same issue existed with apache2 and other services as well.
And every SSH to VR would also time consuming. 
> The new approach of reprogramming VR, would help greatly on this issue, and hopefully
great reduce the VR programming time. It would introduce a mechanism to "aggregate" the commands
to be executed, and do it in one batch inside VR. And restart the related services(if necesary)
only after the whole batch is completed. The configuration would be transfer to VR in one
piece as well, eliminate any unnecessary ssh.
> We would expect in such scenario, most configuration would only be text update and involve
no more time consuming operations. We would leave every possible time consuming operation
to the end of execution of aggregated commands.

This message was sent by Atlassian JIRA

View raw message