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 Icehouse through to Train 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 are upgrading an existing downlevel deployment for SMO.
-
you have deployed a SIMPL VM, and have followed all the pre-upgrade steps.
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
See CSAR EFIX patches to learn more on the CSAR EFIX patching process.
Step 2 - Upgrade the downlevel SMO VMs
The VM with the Rhino node that has the lowest ID must be upgraded last.
Upgrade all of the other VMs using the following command:
csar update --vnf smo --sites <site> --service-group <service_group> --index-range <range> --sdf <path to SDF>.
The indexes start from 0, therefore 0 is the first VM.
The --index-range accepts ranges as well as comma separated indexes (e.g. 1-3,7,9).
To upgrade the VMs in stages, run the command multiple times using the appropriate --index-range values.
The following will occur one SMO node at a time:
-
The downlevel node will be quiesced.
-
The uplevel node will be created and boot up.
-
The VM will automatically start applying configuration from the files you uploaded to CDS in the above steps. During this phase, the status of the VM in MDM will be Orange.
-
Once configuration is complete, the status will change to Green, and the node will be ready for service. At this point the
csar updatecommand will move on to the next SMO VM, or report that the upgrade of the SMO was successful if all nodes have now been upgraded. -
Once the upgrade is complete, place calls and run any additional validation tests to verify the uplevel VMs are working as expected.
Backout procedure
If the upgrade has brought up uplevel VMs to replace the downlevel VMs, then the uplevel VMs can be rolled back to the downlevel VMs. To rollback, repeat the steps above with the downlevel SMO CSAR and downlevel SDF. The lowest uplevel VM must be rolled back last. For example, if VMs 2-5 are in the uplevel, you must rollback VMs 3-5 then rollback VM 2.
You may need to use the --skip pre-update-checks flag as part of the csar update command.
The --skip pre-update-checks flag allows rollbacks when a node is unhealthy.
If the upgrade has failed to bring up the uplevel VMs or the rollback has failed to bring up the downlevel VMs,
then you must redeploy the downlevel VMs.
run csar redeploy --vnf smo --sites <site> --sdf <path to SDF>.
Diagnostics during the quiesce stage
When the downlevel VMs are quiesced, they upload some diagnostics to the CDS. These may be useful if the upgrade or rollback fails.
To get these diagnostics, follow instructions from Retrieving Initconf, Rhino and SGC logs with export-log-history.
Next Step
Follow the post upgrade instructions here: Post rolling upgrade using CSAR EFIX patch steps
