Page History

Overview

Cloudstack CloudStack 4.6 introduces a new way of configuring routers (basic, isolated and VPC). The new code is intended to achieve two goals:

...

The management server sends two components to the router (via the normal communication channels that are hypervisor dependent).  

1. A json JSON file 
2. and a command to execute.

The json JSON file sent varies according to the command being executed.  The command to execute is always update_config.py with a single parameter, the name of the json JSON file to process. The json JSON file is place in the directory /var/cache/cloud on the router.  The actual processing of the file occurs via merge.py.

For instance the ipassociation command will send data to either add or remove an ip address from the router.  The data in the json JSON will be merged with the existing ip addresses on the router and either added or removed from the central configuration.    The The central config files are stored in /etc/cloudstack.

...

...

• Keepalived is left to decide who will be master and who will be backup. We do not interfere with this process but instead simply report it to the management server. This daemon has undergone many years of development to avoid split brains etc.  We do not see a role for cloudstack CloudStack to try and reinvent this wheel.
• VRRP traffic goes over the lowest configured guest interface.  This means, that a VPC router is not redundant until it has at least one guest network configured!
• Adding a new guest network can cause a master/backup election and can cause disruption to the network traffic for some seconds.
• Script based provisioning, think Terraform etc. goes very fast and Keepalived takes some time to settle down. You may see a situation in which when many provisioning commands are sent one after the other affecting guest networks that it takes 20-30 seconds to settle down.