Planning for the procedure
Background knowledge
This procedure assumes that:
-
you are installing into an existing OpenStack deployment
-
The OpenStack deployment must be set up with support for Heat templates.
-
-
you are using an OpenStack version from Newton through to Wallaby inclusive
-
you are thoroughly familiar with working with OpenStack machines and know how to set up tenants, users, roles, client environment scripts, and so on.
(For more information, refer to the appropriate OpenStack installation guide for the version that you are using here.)
-
you have deployed a SIMPL VM, unpacked the CSAR, and prepared an SDF.
Reserve maintenance period
This procedure does not require a maintenance period. However, if you are integrating into a live network, we recommend that you implement measures to mitigate any unforeseen events.
Tools and access
You must have access to the SIMPL VM, and the SIMPL VM must have the right permissions on the OpenStack deployment.
Determine Parameter Values
In the below steps, replace parameters marked with angle brackets (such as <deployment ID>)
with values as follows.
(Replace the angle brackets as well, so that they are not included in the final command to be run.)
-
<path to SDF>: The path to the SDF file on SIMPL VM. For example,/home/admin/current-config/sdf-rvt.yaml. -
<yaml-config-file-directory>: The path to the directory file where config is located on SIMPL VM. For example,/home/admin/current-config/ -
<vm version>: The version of the VM that is deployed. For example,4.2-8-1.0.0. -
<CDS address>: The management IP address of the first TSN node. -
<CDS auth args>(authentication arguments): If your CDS has Cassandra authentication enabled, replace this with the parameters-u <username> -k <secret ID>to specify the configured Cassandra username and the secret ID of a secret containing the password for that Cassandra user. For example,./rvtconfig -c 1.2.3.4 -u cassandra-user -k cassandra-password-secret-id ….If your CDS is not using Cassandra authentication, omit these arguments.
-
<deployment ID>: The deployment ID. You can find this at the top of the SDF. -
<site ID>: A number for the site in the formDC1throughDC32. You can find this at the top of the SDF. -
<site name>: The name of the site managed by a csar command. This is required by somecsarcommands when there are multiple sites defined by a single SDF file:deploy,delete,update, andredeploy. When this optional parameter is skipped, the csar command is applied to VMs from all the sites defined on the SDF file. -
<any TSN IP>: The management IP address of any TSN node.
Method of procedure
|
Refer to the SIMPL VM Documentation for details on the commands mentioned in the procedure. |
Step 1 - Check OpenStack quotas
The SIMPL VM creates one server group per VM, and one security group per interface on each VM. OpenStack sets limits on the number of server groups and security groups through quotas.
View the quota by running openstack quota show <project id> on OpenStack Controller node.
This shows the maximum number of various resources.
You can view the existing server groups by running openstack server group list.
Similarly, you can find the security groups by running openstack security group list
If the quota is too small to accommodate the new VMs that will be deployed,
increase it by running
openstack quota set --<quota field to increase> <new quota value> <project ID>. For example:
openstack quota set --server-groups 100 125610b8bf424e61ad2aa5be27ad73bb
Step 2 - Deploy the OVA
Run csar deploy --vnf tsn --sdf <path to SDF> --sites <site name>.
This will validate the SDF, and generate the heat template. After successful validation, this will upload the image, and deploy the number of TSN nodes specified in the SDF.
|
Only one node type should be deployed at the same time. I.e. when deploying these TSN nodes, don’t deploy other node types at the same time in parallel. |
Step 3 - Validate TSN RVT configuration
Validate the configuration for the TSN nodes to ensure that each TSN node can properly self-configure.
To validate the configuration after creating the YAML files, run
rvtconfig validate -t tsn -i <yaml-config-file-directory>
on the SIMPL VM from the resources subdirectory of the TSN CSAR.
Step 4 - Upload TSN RVT configuration
Upload the configuration for the TSN nodes to the CDS. This will enable each TSN node to self-configure.
To upload configuration after creating the YAML files and validating them as described above, run
rvtconfig upload-config -c <CDS address> <CDS auth args> -t tsn -i <yaml-config-file-directory> (--vm-version-source this-rvtconfig | --vm-version <vm version>)
on the SIMPL VM from the resources subdirectory of the TSN CSAR.
See Example configuration YAML files for example configuration files.
An in-depth description of RVT YAML configuration can be found in the Rhino VoLTE TAS Configuration and Management Guide.
Backout procedure
To delete the deployed VMs, run
csar delete --vnf tsn --sdf <path to SDF> --sites <site name>.
You must also delete the MDM state for each VM. To do this, you must first SSH into one of the MDM VMs.
-
Get the instance IDs by running:
mdmhelper instance list --concise. That will provide the <VM instance ID> of each VM that is in the deployment. -
Then for each TSN VM, run the following command:
mdm-remove-vnfcis <VM instance ID>. Repeat using the instance ID of each managed VM that has been destroyed. -
Run the following command to verify that the configuration has been removed from MDM’s database, specifying the destroyed VM’s instance ID:
mdmhelper instance get <VM instance ID>. This should returnInstance with id <VM instance ID> not found. -
Run the following command to verify that the VMs have been removed from MDM:
mdmhelper instance list --concise. Verify that the VMs you deleted are no longer listed. -
You may now log out of the MDM VM.
