Overview
The following sections describe how to upgrade Cisco Nexus Dashboard Orchestrator that is deployed in Cisco Nexus Dashboard from release 3.2(x) or later to release 4.0(1) or later.
Note |
If you are already running 4.0(1) or later release, skip this section and follow the instructions described in Upgrading from Existing 4.0(x) Release instead. |
Beginning with Release 4.0(1), Nexus Dashboard Orchestrator will validate and enforce a number of best practices when it comes to template design and deployment:
-
All policy objects must be deployed in order according to their dependencies.
For example, when creating a bridge domain (BD), you must associate it with a VRF. In this case, the BD has a VRF dependency so the VRF must be deployed to the fabric before or together with the BD. If these two objects are defined in the same template, then the Orchestrator will ensure that during deployment, the VRF is created first and associate it with the bridge domain.
However, if you define these two objects in separate templates and attempt to deploy the template with the BD first, the Orchestrator will return a validation error as the associated VRF is not yet deployed. In this case you must deploy the VRF template first, followed by the BD template.
-
All policy objects must be undeployed in order according to their dependencies, or in other words in the opposite order in which they were deployed.
As a corollary to the point above, when you undeploy templates, you must not undeploy objects on which other objects depend. For example, you cannot undeploy a VRF before undeploying the BD with which the VRF is associated.
-
No cyclical dependencies are allowed across multiple templates.
Consider a case of a VRF (
vrf1
) associated with a bridge domain (bd1
), which is in turn associated with an EPG (epg1
). If you createvrf1
intemplate1
and deploy that template, then createbd1
intemplate2
and deploy that template, there will be no validation errors since the objects are deployed in correct order. However, if you then attempt to createepg1
intemplate1
, it would create a circular dependency between the two template, so the Orchestrator will not allow you to savetemplate1
addition of the EPG.
Due to these additional rules and requirements, an upgrade to release 4.0(1) or later from an earlier release requires an analysis of all existing templates and conversion of any template that does not satisfy the new requirements. This is done automatically during the migration process described in the following sections and you will receive a detailed report of all the changes that had to be applied to your existing templates to make them compliant with the new best practices.
Note |
You must ensure that you complete all the requirements described in the following "Prerequisites and Guidelines" section before you back up your existing configuration to be migrated to release 4.0(1). Failure to do so may result in template conversion to fail for one or more templates and require you to manually resolve the issues or restart the migration process. |
Upgrade Workflow
The following list provides a high level overview of the migration process and the order of tasks you will need to perform.
-
Review the upgrade guidelines and complete all prerequisites.
-
Back up existing Nexus Dashboard Orchestrator configuration and download the backup to your local machine.
-
Disable and completely uninstall the Nexus Dashboard Orchestrator service from your Nexus Dashboard cluster.
This is mandatory for physical Nexus Dashboard clusters because you will deploy release 4.0(1) on the same cluster.
However, if your Nexus Dashboard cluster is virtual, you can choose to deploy a brand new cluster and install Nexus Dashboard Orchestrator release 4.0(x) in it. After the new cluster is up and running, you can disconnect the old cluster's VMs and complete the migration process on the new cluster. This allows you to preserve your existing cluster and easily bring it back in service in case of any issue with the migration procedure.
-
If necessary, upgrade the Nexus Dashboard cluster.
Similarly to the previous step, if your cluster is virtual, you can choose to preserve it and deploy a new virtual cluster to complete the migration.
-
Install the target 4.0(x) release of Nexus Dashboard Orchestrator.
-
Add a remote location for backups to the fresh Nexus Dashboard Orchestrator instance, upload the backup you took on your previous release, and restore the configuration backup in the new NDO service.