FR12 introduce basic support for comma-separated list of management
servers for agents, while makes an explicit LB unnecessary.
On the agent side, the 'host' is saved as:
<comma separated addresses>@<algorithm name>.
Where the algorithm name is the name of the lb algorithm. The
This FR introduces two new global settings:
- indirect.agent.lb.algorithm: The algorithm for the indirect agent LB.
- indirect.agent.lb.check.interval: The preferred host check interval
for the agent's background task that checks and switches to agent's
preferred host.
Any changes to the above two global settings and the 'host' setting does
not require restarting of the management server(s).
The indirect.agent.lb.algorithm supports following algorithm options:
- static: use the list as provided.
- roundrobin: evenly spreads hosts across management servers.
- shuffle: (pseudo) randomly sorts the list (not recommended for production).
From the agent's perspective, the first address in the propagated list
will be considered the preferred host. A new background task can be
activated by configuring the indirect.agent.lb.check.interval which is
a cluster level global setting from CloudStack or admins can override
this by configuring the 'host.lb.check.interval' in the host's
agent.properties file.
Comma-separated management server list is propagated to agents on
following cases:
- Addition of a host (including ssvm, cpvm systevms).
- Connection or reconnection by the agents to a management server.
- After admin changes the 'host' and/or the
'indirect.agent.lb.algorithm' global settings.
First the agent connects to the management server and sends its current
management server list, which is compared by the management server and
in case of failure a new/update list is sent for the agent to persist.
Every time agent gets a ms-host list and the algorithm, the host specific
background check interval is also sent and it dynamically reconfigures
the background task without need to restart agents.
The 'static' and 'roundrobin' algorithms, strictly checks for the order
as expected by them, however, the 'shuffle' algorithm just checks for
content and not the order of the comma separate ms host addresses.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
From b3f18e7d74, the zone level systemvm local
storage setting never worked as it needed to be moved to config depot.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Also intoroduced one more global config parameter - api.servlet.endpoint (default value is "http://localhost:8080/client/api?"). The parameter defines API end point. Can be used by CS components/services deployed remotely, for sending CS API requests
Introduction of a new Transaction API that is more consistent with the style
of Spring's transaction managment. The existing Transaction class was renamed
to TransactionLegacy. All of the non-DAO code in the management server has been
updated to use the new Transaction API.
ACS is now comprised of a hierarchy of spring application contexts.
Each plugin can contribute configuration files to add to an existing
module or create it's own module.
Additionally, for the mgmt server, ACS custom AOP is no longer used
and instead we use Spring AOP to manage interceptors.
The managed context framework provides a simple way to add logic
to ACS at the various entry points of the system. As threads are
launched and ran listeners can be registered for onEntry or onLeave
of the managed context. This framework will be used specifically
to handle DB transaction checking and setting up the CallContext.
This framework is need to transition away from ACS custom AOP to
Spring AOP.
Rohit Yadav
Hugo Trippaers
Marcus Sorensen
Daan Hoogland
Alena Prokharchyk
Miguel Ferreira
Alex Huang
Syed
Darren Shepherd
dhoogland
Darren Shepherd
Prasanna Santhanam
Chip Childers
Bharat Kumar
Nitin Mehta