This blueprint describes adding or deleting flow collector nodes to existing Contrail cluster at run time.
Once flow-colletors are added via Contrail UI Setup wizard, we do not have any way to add new flow-collector node to existing Contrail cluster or delete existing flow-collector node, or to add flow-collector node to already deployed contrail cluster without previously deployed flow-collector nodes. So, user should be able to add or delete flow-collector node after contrail has been deployed.
There may be three cases of adding or deleting flow collector nodes. b. Add flow collector node(s) to a Contrail Cluster without any existing flow collector node. a. Add flow collector node(s) to a Contrail Cluster with existing flow collector nodes. c. Delete flow collector node(s) from a Contrail Cluster.
In all the above cases, proposed solution is to modify the existing instances.yml, as generated by contrail command deployer in contrail command node while provisioning contrail cluster using Contrail Command UI, to add or delete flow collector nodes and run below CLI command:
cd /usr/share/contrail/appformix-ansible-deployer/xflow/
source venv/bin/activate
bash deploy_insights.sh <instance.yml file> -cluster-id <contrail_cluster_id>
N/A
None
There will be no UI Change initially.
N/A
When a new flow-collector node is added or existing flow-collector node is deleted using instances.yml, then ansible playbook will run to first cleanup the flow-collector nodes which need to be deleted and then ansible playbook will run to setup the new flow-collector nodes and to form the cluster.
In deployer, we will first derive the installed flow-collector nodes from database, and then will compare with the new instances, if some flow-collector node is deleted, then we create inventory file with those deleted nodes and run the cleanup playbook, then will run the setup playbook to setup the rest of the cluster with new flow-collector nodes.
If nodes are added, then there is no issue while cluster to rebuild. If nodes are deleted from cluster, then downscale of kafka is maintained below way: Before running the cleanup playbook, first get the below znode details from the zookeeper:
/brokers/ids/<broker_id>
/brokers/topics/vflow_flows_protobuf/partitions
From the first znode, we get the already assigned broker id, if same node is found in instances.yml, then deployer will assign the same broker id to that kafka node
From the second znode, we get the partitions count and details for the
vflow_flows_protobuf topic, which is used while reassign in downscale
and ignored while upscale, as upscale case we use partition count as
number of nodes * adapter count where adapter count per node by default is 3
N/A
N/A
N/A
N/A
N/A
JIRA story : https://contrail-jws.atlassian.net/browse/CEM-9294