Upgrading Automatically Via Service Catalog
Overview
Prerequisites and Guidelines
Upgrade Your Nexus Dashboard Cluster
Upgrading Orchestrator Service Using Cisco App Store
Upgrading Orchestrator Service Manually
Finalize Database Upgrade
Resolve Configuration Drifts

Upgrading Automatically Via Service Catalog

Overview

There are two approaches when it comes to upgrading your Nexus Dashboard Orchestrator:

Upgrading in-place by upgrading each component (such as the Nexus Dashboard platform and the Orchestrator service) in sequence.

This approach is described in this chapter and is recommended in the following cases:
- If you are using a physical Nexus Dashboard cluster.
- If you are running a recent release of Nexus Dashboard (2.2.2 or later) and Nexus Dashboard Orchestrator (3.7.1 or later).
  
  While you can use this approach to upgrade any Orchestrator release 3.3(1) or later, it may require upgrading the underlying Nexus Dashboard platform before you can upgrade the Orchestrator service. In those cases, an upgrade via configuration restore described below may be faster and simpler.
Deploy a brand new Nexus Dashboard cluster, installing a new NDO service instance in it and transferring existing Orchestrator configuration via the configuration restore workflow

This approach is described in Upgrading Manually Using Configuration Restore and is recommended in the following cases:
- If you are running any release of Nexus Dashboard Orchestrator or Multi-Site Orchestrator prior to release 3.3(1).
  
  In this case you must upgrade using configuration restore because in-place upgrade is not supported.
- If you are using a virtual Nexus Dashboard cluster and running an older release of Nexus Dashboard Orchestrator.
  
  Upgrading from an old Nexus Dashboard Orchestrator release requires upgrading the underlying Nexus Dashboard platform as well, in which case deploying a new cluster and restoring configuration may shorten the required maintenance window.
  
  This also allows you to simply disconnect the existing cluster and keep the existing VMs until the upgrade is complete in case you want to revert to the previous version or the upgrade does not succeed.

Changes in Release 4.0(1) and Later

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 create vrf1 in template1 and deploy that template, then create bd1 in template2 and deploy that template, there will be no validation errors since the objects are deployed in correct order. However, if you then attempt to create epg1 in template1, it would create a circular dependency between the two template, so the Orchestrator will not allow you to save template1 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 upgrade 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 for the upgrade. 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 upgrade process and the order of tasks you will need to perform.

Review the upgrade guidelines and complete all prerequisites.
If necessary, disable the existing Nexus Dashboard Orchestrator service and upgrade the Nexus Dashboard cluster.

This is mandatory if your Nexus Dashboard release is 2.2(1) or earlier as you need to also upgrade the Nexus Dashboard platform software, which requires all services to be disabled during the upgrade.

However, if your Nexus Dashboard cluster is virtual, you can choose to deploy a brand new cluster and install Nexus Dashboard release 2.3(2b) or later along with the Orchestrator service release 4.1(2) 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, which allows you to preserve your existing cluster and easily bring it back in service in case of any issue with the migration procedure. This effectively turns the upgrade into a manual upgrade using the backup restore approach, and in this case we recommend following the instructions described in Upgrading Manually Using Configuration Restore instead

Re-enable your existing Orchestrator service, then upload and activate Nexus Dashboard Orchestrator release 4.1(2) or later.

Note

Running the older version of NDO in the newer Nexus Dashboard is supported in a limited capacity for NDO upgrade purposes only. You must upgrade to NDO release 4.1(2) or later as described in this document.

Finalize the upgrade and resolve any configuration drifts.

Prerequisites and Guidelines

Before you upgrade your Cisco Nexus Dashboard Orchestrator cluster:

Ensure that you are running Nexus Dashboard Orchestrator release 3.3(1) or later.

Note

If you are running a release prior to 3.3(1), you must skip this chapter and follow the instructions described in Upgrading Manually Using Configuration Restore instead.

Note that downgrading from this release is not supported.

If you ever want to downgrade, you can deploy a brand-new cluster using the earlier version and then restore configuration from the earlier release. Note that you cannot restore a backup created on a newer version in an older version, in other words restoring a backup from release 4.1(2) in release 3.7(1) is not supported.
Ensure that your current Nexus Dashboard cluster is healthy.

You can check the Nexus Dashboard cluster health in one of two ways:
- By logging into your Nexus Dashboard GUI and verifying system status in the System Overview page.
- By logging into any one of the nodes directly as rescue-user and running the following command:
```
# acs health
All components are healthy
```
Ensure that your current Cisco Nexus Dashboard Orchestrator is healthy.

Depending on your existing Orchestrator version, you can check the service status in one of two ways:
- For recent NDO releases, check the Nexus Dashboard's Overview page that shows the platform and services' health.
- For older Orchestrator releases, you can check the status of you Nexus Dashboard Orchestrator service by navigating to Settings > System Status:
  Then ensure that the status of all nodes and services is healthy:
Ensure that there are no configuration drifts before you back up your existing configuration.

This applies to all template types available in your existing release, such as application, tenant policies, fabric policies, and fabric resource policies templates.

If your existing Nexus Dashboard Orchestrator is release 3.7(1) or later, you can use the drift reconciliation workflow for application templates, as described in the "Configuration Drifts" section of the Nexus Dashboard Orchestrator Configuration Guide.
Back up and download your existing Orchestrator configurations.

Configuration backups are described in the "Backup and Restore" chapter of the Nexus Dashboard Orchestrator Configuration Guide for your release.
Back up and download your existing fabrics' configurations.

We recommend running configuration drift reconciliation after you upgrade your Nexus Dashboard Orchestrator, which may require you to redeploy configurations to your fabrics. As such, we recommend creating configuration backups of all fabrics managed by your Nexus Dashboard Orchestrator.

For more information on creating Cisco APIC configuration backups, see the "Management" chapter of the Cisco APIC Basic Configuration Guide for your release.

For more information on creating Cisco Cloud Network Controller configuration backups, see the "Configuring Cisco Cloud Network Controller Components" chapter of the Cisco Cloud Network Controller User Guide for your release.

For more information on creating Cisco Nexus Dashboard Fabric Controller configuration backups, see the "Backup and Restore" chapter of the Cisco NDFC Fabric Controller Configuration Guide for your release.
Note that if you have template versioning enabled (supported since release 3.4(1)), only the latest versions of the templates are preserved during the upgrade.

All other existing versions of templates, including older versions that are tagged Golden, will not be transferred.
Ensure that all templates are in a supported state before creating the configuration backup of the existing cluster:
- Templates that are undeployed or were never deployed after they were created require no additional attention and will be migrated during the upgrade.
- All deployed templates must have no pending configuration changes.
  
  If you have one or more templates that have been modified since they were last deployed, you must either deploy the latest version of the template or undo the changes to the template since it was deployed by reverting to the last-deployed version and re-deploying it.

When upgrading the Orchestrator service, you can do so in one of two ways:

Using the Nexus Dashboard's App Store, as described in Upgrading Orchestrator Service Using Cisco App Store.

In this case, the Cisco DC App Center must be reachable from the Nexus Dashboard via the Management Network directly or using a proxy configuration. Nexus Dashboard proxy configuration is described in the Nexus Dashboard User Guide.

Note

The App Store allows you to upgrade to the latest available version of the service only. If you want to upgrade to a different release, you must use the manual upgrade process as described below.

By manually uploading the new app image, as described in Upgrading Orchestrator Service Manually.

You can use this approach if you are unable to establish the connection to the DC App Center or if you want to upgrade to a version of the service that is not the latest available release.

SR-MPLS and SDA integration configurations are not transferred during the upgrade.

If you have either of these integrations in your deployment, it will not affect the migration, but you will receive a notification and will need to reconfigure them after you complete the upgrade.
If you plan to add and manage new Cloud Network Controller sites after you upgrade your Nexus Dashboard Orchestrator to this release, ensure that they are running Cloud Network Controller release 5.2(1) or later.

On-boarding and managing Cloud Network Controller sites running earlier releases is not supported.

Upgrade Your Nexus Dashboard Cluster

Before you upgrade to release 4.1(2) of Nexus Dashboard Orchestrator, you must upgrade the Nexus Dashboard cluster to release 2.2.2 or later as described in this section.

Note

If your Nexus Dashboard cluster is already on release 2.2.2 or later, you can choose to skip this section; but we recommend upgrading to Nexus Dashboard release 2.3.2.

Before you begin

You must have the following completed:

Backed up and downloaded the existing Nexus Dashboard Orchestrator configuration.

Before upgrading the Nexus Dashboard cluster:

Check your existing Nexus Dashboard release.

At a minimum, you must upgrade to Nexus Dashboard release 2.2.2. If you are already running release 2.2.2 or later, you can skip this section.

If you do need to upgrade from an earlier release, we recommend upgrading to release 2.3.2.

Note

Nexus Dashboard supports direct upgrades between specific sets of releases only:

If you are on release 2.1.2 or later, you can upgrade directly to release 2.3.2.
If you are on a release prior to release 2.1.2, you must first upgrade to release 2.2.2 and then to release 2.3.2.

Ensure that you have read the Release Notes for every upgrade hop's target release for any changes in behavior, guidelines, and issues that may affect your upgrade.

The upgrade process is the same for all Nexus Dashboard form factors. Regardless of whether you deployed your cluster using physical servers, VMware ESX, Linux KVM, Azure, or AWS, you will use the target release's ISO image to upgrade.
Ensure that your current Nexus Dashboard cluster is healthy.

You can check the system status on the System Overview page of the Nexus Dashboard GUI or by logging in to one of the nodes as rescue-user and ensuring that the acs health command returns All components are healthy.
We recommend that you create a backup of the existing Nexus Dashboard cluster configuration prior to the upgrade.
Ensure that no configuration changes are made to the cluster, such as adding worker or standby nodes, while the upgrade is in progress.
If you are upgrading Nexus Dashboard from release 2.1(1) or earlier, you may need to clear your browser cache after the upgrade is completed for the UI to show properly.

Procedure

Step 1

Download the Nexus Dashboard image.

If you have to upgrade across multiple hops as mentioned in the Before you begin section above, download the images for every target hop.

Browse to the Software Download page.

https://software.cisco.com/download/home/286327743/type/286328258
Choose the Nexus Dashboard version you want to download.

Download the Cisco Nexus Dashboard image (nd-dk9.<version>.iso).

Note

You must download the .iso image for all upgrades, even if you used the VMware ESX .ova image or a cloud provider's marketplace for initial cluster deployment.

(Optional) Host the image on a web server in your environment.

When you upload the image to your Nexus Dashboard cluster, you will have an option to provide a direct URL to the image.

Step 2

Step 3

Disable all installed services in the cluster.

When you upgrade Nexus Dashboard, all currently installed services, such as Nexus Dashboard Orchestrator or Nexus Dashboard Insights, must be disabled.

Step 4

Upload the new Nexus Dashboard image to the cluster.

Note

Note that the UI may differ slightly across different Nexus Dashboard releases, but the navigation remains the same.

Navigate to Operations > Firmware Management.
Select the Images tab.
From the Actions menu, select Add Image.

Step 5

Select the new image.

Note

If you have to upgrade over multiple hops, you must upload only one image at a time for the immediate release to which you are upgrading. Then after the upgrade to that hop is complete, you can repeat the process with the image for the next hop.

In the Add Firmware Image window, select Local.

Alternatively, if you hosted the image on a web server, choose Remote instead.
Click Select file and select the ISO image you downloaded in the first step.

If you chose to upload a remote image, provide the file path for the image on the remote server.
Click Upload to add the image.

The image will be uploaded to the Nexus Dashboard cluster, unpacked, processed, and made available for the upgrade. The whole process may take several minutes and you will be able to see the status of the process in the Images tab.

Step 6

Wait for the image status to change to Downloaded.

You can check the status of the image download progress in the Images.

Step 7

Set up the update.

Navigate to Operations > Firmware Management.
Select the Updates tab.
Click Setup Update.

The Firmware Update screen opens.

Step 8

Choose the upgrade image.

In the Firmware Update > Version selection screen, select the firmware version you uploaded and click Next.
In the Firmware Update > Confirmation screen, verify the details and click Begin Install.

The installation progress window is displayed. You can navigate away from this screen while the update is in progress. To check on the update status at a later time, navigate to the Firmware Management screen and click View Details in the Last Update Status tile.

This will set up the required Kubernetes images and services but will not switch the cluster to the new version. The cluster will continue to run the existing version until you activate the new image in the next step. The entire process may take up to 20 minutes.

Step 9

Activate the new image.

Navigate back to the Operations > Firmware Management screen
In the Last Update Status tile, click View Details.
Click Activate.
In the Activation Confirmation window, click Continue.

It may take up to 20 additional minutes for all the cluster services to start and the GUI to become available. The page will automatically reload when the process is completed.

Step 10

If you upgraded a virtual cluster deployed in VMware ESX, convert the nodes to the new profile.

Note

If your cluster is not deployed in VMware ESX or is already on release 2.1.1 or later, skip this step.

Starting with Release 2.1.1, Nexus Dashboard supports two different node profiles for virtual nodes deployed in VMware ESX. After the upgrade, you must convert all the nodes of the existing cluster to one of the new profiles:

Data node—node profile designed for data-intensive applications, such as Nexus Dashboard Insights
App node—node profile designed for non-data-intensive applications, such as Nexus Dashboard Orchestrator

The profile you choose depends on your use case scenario:

If you plan to run only the Nexus Dashboard Orchestrator service, convert all nodes to the App node profile.
If you plan to run Nexus Dashboard Insights or co-host applications, you must convert the nodes to the Data profile.

You convert the nodes to the new profile by deploying brand new nodes using that profile and replacing existing nodes with them one at a time.

Bring down one of the nodes.

You must replace one node at a time.
Deploy a new node in VMware ESX using the App or Data profile OVA.

When deploying the new node, you must use the same exact network configuration parameters as the node you are replacing.
Log in to the existing Nexus Dashboard GUI.

You can use the management IP address of one of the remaining healthy master nodes.
From the left navigation pane, select System Resources > Nodes.

The node you are replacing will be listed as Inactive.
Click the (...) menu next to the inactive master node you want to replace and select Replace.

The Replace window will open.
Provide the Management IP Address and Password for the node, then click Verify.

The cluster will connect to the new node's management IP address to verify connectivity.
Click Replace.

It may take up to 20 minutes for the node to be configured and join the cluster.
Wait for the cluster to become healthy, then repeat this step for the other two nodes.

Step 11

After the upgrade is successful, delete the upgrade image you had uploaded.

You must remove the older upgrade images before uploading a new image for the next upgrade.

Step 12

If you are upgrading across multiple hops, repeat these steps for each upgrade one at a time.

Upgrading Orchestrator Service Using Cisco App Store

This section describes how to upgrade Cisco Nexus Dashboard Orchestrator.

Before you begin

Ensure that you have completed the prerequisites described in Prerequisites and Guidelines.
Ensure that Cisco DC App Center is reachable from the Nexus Dashboard via the Management Network directly or using a proxy configuration.

Nexus Dashboard proxy configuration is described in the Nexus Dashboard User Guide

Procedure

Step 1

Step 2

From the left navigation menu, select Services.

Step 3

Re-enable the existing version of Nexus Dashboard Orchestrator.

If you had to disable the NDO service in order to upgrade the Nexus Dashboard platform as described in the previous section, you must re-enable it before upgrading to NDO release 4.1(2) or later.

Note

Step 4

Upgrade the application using the App Store.

In the Services screen, select the App Store tab.
In the Nexus Dashboard Orchestrator tile, click Upgrade.
In the License Agreement window that opens, click Agree and Download.

Step 5

Wait for the new image to initialize.

It may take up to 20 minutes for the new application image to become available.

Step 6

Activate the new image.

In the Services page, select the Installed Services tab.
In the top right corner of the Nexus Dashboard Orchestrator tile, click the menu (...) and choose Available Versions.

In the available versions window, click Activate next to the new image.

Note

Do not Disable the currently running image before activating the new image. The image activation process will recognize the currently running image and perform the upgrade workflows necessary for the currently running version.

It may take up to 20 additional minutes for all the application services to start and the GUI to become available. The page will automatically reload when the process is completed.

Step 7

Delete the old service image.

Because service downgrades are not supported, we recommend that you delete the older images from your Nexus Dashboard after you upgraded.

In the Services page, select the Installed Services tab.
In the top right corner of the Nexus Dashboard Orchestrator tile, click the menu (...) and choose Available Versions.
In the available versions window, click the delete icon next to the image you want to delete.

What to do next

After you have upgraded the NDO service, you must finalize the upgrade from the NDO UI as described in Finalize Database Upgrade.

Upgrading Orchestrator Service Manually

This section describes how to upgrade Cisco Nexus Dashboard Orchestrator.

Before you begin

Ensure that you have completed the prerequisites described in Prerequisites and Guidelines.

Procedure

Step 1

Download the target NDO release image.

Browse to the Nexus Dashboard Orchestrator page on DC App Center:

https://dcappcenter.cisco.com/nexus-dashboard-orchestrator.html
From the Version dropdown, choose the version you want to install and click Download.
Click Agree and download to accept the license agreement and download the image.

Step 2

Step 3

Re-enable the existing version of Nexus Dashboard Orchestrator.

If you had to disable the NDO service in order to upgrade the Nexus Dashboard platform as described in the previous section, you must re-enable it before upgrading to NDO release 4.1(2) or later.

Note

Step 4

Upload the new NDO image to your Nexus Dashboard.

From the left navigation menu, select Services.
In the Nexus Dashboard's Services screen, select the Installed Services tab.
From the Actions menu in the top right of main pane, select Upload App.
In the Upload App window, choose the location of the image

If you downloaded the application image to your system, choose Local.

If you are hosting the image on a server, choose Remote.
Choose the file.

If you chose Local in the previous substep, click Select File and select the app image you downloaded.

If you chose Remote, provide the full URL to the image file, for example http://<ip-address>:<port>/<full-path>/cisco-mso-<version>.nap.
Click Upload to add the app to the cluster.

A new tile will appear with the upload progress bar. Once the image upload is completed, the Nexus Dashboard will recognize the new image as an existing application and add it as a new version.

Step 5

Wait for the new image to initialize.

It may take up to 20 minutes for the new application image to become available.

Step 6

Activate the new image.

In the Services page, select the Installed Services tab.
In the top right corner of the Nexus Dashboard Orchestrator tile, click the menu (...) and choose Available Versions.

In the available versions window, click Activate next to the new image.

Note

It may take up to 20 additional minutes for all the application services to start and the GUI to become available. The page will automatically reload when the process is completed.

Step 7

Delete the old service image.

Because service downgrades are not supported, we recommend that you delete the older images from your Nexus Dashboard after you upgraded.

In the Services page, select the Installed Services tab.
In the top right corner of the Nexus Dashboard Orchestrator tile, click the menu (...) and choose Available Versions.
In the available versions window, click the delete icon next to the image you want to delete.

What to do next

After you have upgraded the NDO service, you must finalize the upgrade from the NDO UI as described in Finalize Database Upgrade.

Finalize Database Upgrade

This section describes how to deploy and configure the new Nexus Dashboard cluster and the NDO service, which you will use to restore your previous configuration.

Before you begin

You must have the following completed:

Backed up and downloaded the existing Nexus Dashboard Orchestrator configuration.
Installed the target Orchestrator release as described in Deploy Nexus Dashboard and Install Nexus Dashboard Orchestrator.

Procedure

Step 1

Open the Orchestrator service UI.

Simply click Open on the service tile in the Nexus Dashboard's Services page.

When you open NDO 4.1(2) or later for the first time, it automatically starts Post Upgrade Validation process.

Step 2

Finalize database upgrade.

Ensure that there are no failures listed in the report, then click Restore and Continue to proceed.
Before the configuration database is updated for this release, the upgrade process performs a number of validations. The validation provides a summary of template and policy changes that are performed during this final upgrade stage in the next step and includes the following:
- Implicit template stretching – if one or more objects are implicitly stretched, the upgrade process will create new explicitly-stretched templates and move the objects into those templates.
  
  For example, if you have a template (t1) that contains vrf1 and is associated to site1 and another template (t2) that contains a BD that references vrf1 but is associated to two sites (site1 and site2), then vrf1 will be implicitly stretched between the two sites.
  
  This is no longer allowed starting with release 4.0(1) and the VRF must be explicitly stretched to both sites. In such cases during the upgrade, the VRF will be either moved to a different template which will be explicitly stretched between both sites or the original template will be associated with both sites, depending on whether the other policies in that template require stretching as well.
  
  Any templates that are created in this case will be named UpgradeTemplate%d, where %d is an incrementing number starting with 1 to ensure that all newly added templates are unique.
- Global policy migration – all global tenant policies (such as DHCP relay or route maps) and fabric policies (such as QoS) will be moved into the new tenant and fabric policy templates that have been added in release 4.0(1).
This is the stage of the upgrade where the existing schemas and templates are recreated in your NDO configuration database according to the current best practices. These schemas and templates are then posted to the local NDO database as if it were a greenfield schema/template creation. Then the newly saved templates are deployed in the correct order that conforms to the current deployment requirements and best practices. The template deployment in this step uses a “local deploy” option to calculate the deployment plan and update the database, but does not send any configuration payload to the sites' controllers.

The upgrade process also checks for any configuration drifts between the local NDO database (configuration that is correct from NDO's point of view) and what is actually deployed in the fabrics. If this release of NDO supports additional objects or properties compared to the release from which you are upgrading, the upgrade will automatically reconcile those drifts by importing the existing configuration from the site's controller.
Review the report from the previous substep and click Ok to finish.

The final stage of the database upgrade presents a full report of the performed actions for you to review. If you close the report but want to review it again, simply click the View Restore Report in the Backups page.

Step 3

Verify that backup was restored successfully and all objects and configurations are present.

In the Sites page, verify that all sites are listed as Managed.
In the Tenants and Schemas pages, confirm that all tenants and schemas from your previous Nexus Dashboard Orchestrator cluster are present.
Navigate to Infrastructure > Site Connectivity and confirm that intersite connectivity is intact.

In the main pane, click Show Connectivity Status next to each site and verify that the existing tunnels are up and connectivity was not interrupted.
In the main pane, click Configure to open Fabric Connectivity Infra screen and verify External Subnet Pool addresses.

You can view the external subnet pools by selecting General Settings > IPsec Tunnel Subnet Pools tab of the Fabric Connectivity Infra screen and verify that the External Subnet Pools previously configured in Cloud Network Controller have been imported from the cloud sites.

These subnets are used to address the IPsec tunnel interfaces and loopbacks of the Cloud Routers used for on-premises connectivity and had to be configured directly in the Cloud Network Controller in earlier Nexus Dashboard Orchestrator releases.

Resolve Configuration Drifts

In some cases you may run into a situation where the configuration actually deployed in the site's controller is different from the configuration defined in the Nexus Dashboard Orchestrator. These configuration discrepancies are referred to as Configuration Drifts and are indicated by an Out of Sync warning next to the site name in the template view page as shown in the following figure:

After upgrading your Nexus Dashboard Orchestrator and restoring the previous configuration backup, we recommend that you check for and resolve any configuration drifts that were not automatically resolved by the upgrade process as described in this section.

Note

Deploying any templates before resolving configuration drifts would push the configuration defined in the Orchestrator and overwrite the values defined in the fabrics' controllers.

Procedure

Step 1	In your Nexus Dashboard Orchestrator, navigate to Application Management > Schemas.
Step 2	Select the first schema and check its templates for configuration drifts. You will repeat the following steps for every schema and template in your deployment You can check for configuration drifts in one of the following two ways: Check the template deployment status icon for each site to which the template is assigned. Select the template and click Deploy to sites to bring up the configuration comparison screen to check which objects contain configuration drifts.
Step 3	If the template contains a configuration drift, resolve the conflicts. For more information about configuration drifts, check the "Configuration Drifts" chapter in the Cisco Nexus Dashboard Orchestrator Configuration Guide for ACI Fabrics. Close the template deployment dialog to return to the Schema view. Deploying any templates at this point would push the values in the Orchestrator database and overwrite any existing settings in the fabrics. From the template's Actions menu, select Drift Reconciliation. The Drift Reconciliation wizard opens. In the Drift Reconciliation screen, compare the template-level configurations for each site and choose the one you want. Template-level properties are common across all sites associated to the template. You can compare the template level properties defined on Nexus Dashboard Orchestrator with the configuration rendered in each site and decide what should become the new configuration in the Nexus Dashboard Orchestrator template. Selecting the site configuration will modify those properties in the existing Nexus Dashboard Orchestrator template, whereas selecting the Nexus Dashboard Orchestrator configuration will keep the existing Nexus Dashboard Orchestrator template settings as is Click Go to Site Specific Properties to switch to site-level configuration. You can choose a site to compare that specific site's configuration. Unlike template-level configurations, you can choose either the Nexus Dashboard Orchestrator-defined or actual existing configurations for each site individually to be retained as the template's site-local properties for that site. Even though in most scenarios you will make the same choice for both template-level and site-level configuration, the drift reconciliation wizard allows you to choose the configuration defined in the site's controller at the "Template Properties" level and the configuration defined in Nexus Dashboard Orchestrator at the "Site Local Properties" level or vice versa. Click Preview Changes to verify your choices. The preview will display full template configuration adjusted based on the choices picked in the Drift Reconciliation wizard. Save the schema. Click Deploy to sites to deploy the configuration and finish reconciling the drift for that template
Step 4	Repeat the above steps for every schema and template in your Nexus Dashboard Orchestrator.
Step 5	Check audit logs to verify that all templates have been re-deployed. You can view the audit logs in the Operations tab. Audit Logs page and confirm that all templates show as `Redeployed` to ensure that full re-deployment successfully completed.

Cisco Nexus Dashboard Orchestrator Deployment Guide, Release 4.1(x)

Bias-Free Language

Book Title

Cisco Nexus Dashboard Orchestrator Deployment Guide, Release 4.1(x)

Chapter Title