Skip to content
Network as Code

NDO Undeployment of Templates

In the Nexus Dashboard Orchestrator a schema can contain multiple templates. These templates have to be associated and deployed to ACI sites in order to push the configuration from the template to the APIC.

Deployment of templates can be enabled/disabled by configuring the module attribute deploy_templates. If this attribute is set to true, the templates will be automatically deployed to the APIC after every terraform apply operation. If it is set to false, template deployment will not be managed by Terraform and user must do it manually from NDO GUI.

module "ndo" {
  source  = "netascode/nac-ndo/mso"
  version = "1.1.0"


  yaml_directories = ["data"]


  manage_system            = true
  manage_sites             = true
  manage_site_connectivity = true
  manage_tenants           = true
  manage_schemas           = true
  deploy_templates         = true
}

The deploy_order attribute influences the order of template deployment, where a template with a lower number will always be deployed before a template with a higher number. This is used in scenarios where templates have objects that are dependant on objects configured in other templates, i.e. a VRF created in Template1, and a Bridge Domain using this VRF in another Template2. If all objects are configured within the same template, there is no need to use this flag.

Deployment is done using the mso_schema_template_deploy_ndo resource. Currently the solution supports three levels of template deployment. In the following example there are three templates with different deployment orders:

---
ndo:
  schemas:
    - name: S1
      templates:
        - name: TEMPLATE1
          deploy_order: 1
          <...>
        - name: TEMPLATE2
          deploy_order: 2
          <...>
        - name: TEMPLATE3
          deploy_order: 3
          <...>

This will create three deploy resources which will deployed in the order of TEMPLATE1, TEMPLATE2, and TEMPLATE3

  • Firstly deploy mso_schema_template_deploy_ndo for TEMPLATE1
  • Secondly deploymso_schema_template_deploy_ndo_2 for TEMPLATE2 only once TEMPLATE1 deployment is completed
  • Thirdly deploy mso_schema_template_deploy_ndo_3 for TEMPLATE3 only once TEMPLATE2 deployment is completed

Template undeployment is done using the mso_schema_site resource. This resource will at the same time undeploy template and remove the site association configuration.

Before version 1.1.0 of the module, there was no way to undeploy templates in an ordered manner, which could result in failures. In the example above, if TEMPLATE1 attempted undeployment first, operation would fail because TEMPLATE2 objects still exist and depend on TEMPLATE1. It would be necessary to try several times, until all templates are undeployed in the correct order.

For this reason, starting with version 1.1.0, the module introduced the undeploy_order attribute, which works similarly to the deploy_order attribute. It takes the values assigned for deployment, and reverses them for undeployment. In the example above, the undeployment order would be TEMPLATE3, TEMPLATE2, and TEMPLATE1.

---
ndo:
  undeploy_order: true

Default value for undeploy_order is false which keeps the same behavior as pre-1.1.0 allowing existing deployments to continue working without any changes. If you want to use the new undeployment order, you can set this attribute to true in the module configuration.

For greenfield deployments, it is recommended to set the undeploy_order attribute to true from the start, so that the templates are always undeployed in the correct order. This will ensure that any dependencies between templates are respected during undeployment, preventing potential issues or failures.

For existing deployments that want to start using this attribute, there is a procedure to follow during upgrade in order to avoid a disruption of the existing deployments.

  1. Note down what is the required deploy/undeploy order of the templates. You should already have the deploy_order attribute configured in the templates. The same attribute will be used to indicate order for undeployment.
  2. In the existing deployment upgrade version of the module to 1.1.0 or higher. Run terraform init -upgrade command to download new version of the module.
  3. List the objects in the Terraform statefile and look for mso_schema_site objects for the configured templates: terraform state list | grep mso_schema_site.schema_site

In the example below, there are three templates associated with the site KACI-Site-1 configured in schema ABC:

Terminal window
$ terraform state list | grep mso_schema_site.schema_site


module.ndo.mso_schema_site.schema_site["ABC/TEMPLATE1/KACI-Site-1"]
module.ndo.mso_schema_site.schema_site["ABC/TEMPLATE2/KACI-Site-1"]
module.ndo.mso_schema_site.schema_site["ABC/TEMPLATE3/KACI-Site-1"]
  1. Move these resources to the new resources. New resources are named mso_schema_site.schema_site1, mso_schema_site.schema_site2, and mso_schema_site.schema_site3 where the number corresponds to the deploy_order of the template. In the example above, TEMPLATE1 has deploy order 1, TEMPLATE2 has deploy order 2, and TEMPLATE3 has deploy order 3.
Terminal window
terraform state mv 'module.ndo.mso_schema_site.schema_site["ABC/TEMPLATE1/KACI-Site-1"]' 'module.ndo.mso_schema_site.schema_site1["ABC/TEMPLATE1/KACI-Site-1"]'
terraform state mv 'module.ndo.mso_schema_site.schema_site["ABC/TEMPLATE2/KACI-Site-1"]' 'module.ndo.mso_schema_site.schema_site2["ABC/TEMPLATE2/KACI-Site-1"]'
terraform state mv 'module.ndo.mso_schema_site.schema_site["ABC/TEMPLATE3/KACI-Site-1"]' 'module.ndo.mso_schema_site.schema_site3["ABC/TEMPLATE3/KACI-Site-1"]'
  1. Add the undeploy_order attribute to the module configuration, as described above. Keep in mind that this attribute is set directly under the ndo key, not under the templates.
---
ndo:
  undeploy_order: true
  1. Run terraform plan to verify that there are no changes expected to happen to any of the mso_schema_site resources. If there are changes or recreates, it means that the undeploy_order attribute is not set correctly or the state was not moved correctly. The expected output of the plan should only show that the defaults file must be replaced (always during an upgrade), and that each of the templates will be deployed (as always with terraform apply):
Terminal window
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the
following symbols:
  ~ update in-place
-/+ destroy and then create replacement


Terraform will perform the following actions:


  # module.ndo.local_sensitive_file.defaults[0] must be replaced
-/+ resource "local_sensitive_file" "defaults" {
      ~ content              = (sensitive value) # forces replacement
      ~ content_base64sha256 = "xW8r95QbbDBkPuXdIf4506PrqRoXlT68HmuwO4Sd6ns=" -> (known after apply)
      ~ content_base64sha512 = "fpWJH996oQyXEtup/Z6y5f0M2e54hkuDcvfCswqCwNDLxP1vlU0FsUwnwBzaf1Z4UOATf0b5JdLTfiYaPzOb3w==" -> (known after apply)
      ~ content_md5          = "f3a14c9a3d874d6f011e206e39719d07" -> (known after apply)
      ~ content_sha1         = "c3f36bf05f2e2295320d70bb41161235613e868b" -> (known after apply)
      ~ content_sha256       = "c56f2bf7941b6c30643ee5dd21fe39d3a3eba91a17953ebc1e6bb03b849dea7b" -> (known after apply)
      ~ content_sha512       = "7e95891fdf7aa10c9712dba9fd9eb2e5fd0cd9ee78864b8372f7c2b30a82c0d0cbc4fd6f954d05b14c27c01cda7f567850e0137f46f925d2d37e261a3f339bdf" -> (known after apply)
      ~ id                   = "c3f36bf05f2e2295320d70bb41161235613e868b" -> (known after apply)
        # (3 unchanged attributes hidden)
    }


  # module.ndo.mso_schema_template_deploy_ndo.template["ABC/TEMPLATE1"] will be updated in-place
  ~ resource "mso_schema_template_deploy_ndo" "template" {
      + force_apply   = "always-deploy"
        id            = "688cc9a4dac77052a7a67f76"
        # (3 unchanged attributes hidden)
    }


  # module.ndo.mso_schema_template_deploy_ndo.template2["ABC/TEMPLATE2"] will be updated in-place
  ~ resource "mso_schema_template_deploy_ndo" "template2" {
      + force_apply   = "always-deploy"
        id            = "688cc9a4dac77052a7a67f76"
        # (3 unchanged attributes hidden)
    }


  # module.ndo.mso_schema_template_deploy_ndo.template3["ABC/TEMPLATE3"] will be updated in-place
  ~ resource "mso_schema_template_deploy_ndo" "template3" {
      + force_apply   = "always-deploy"
        id            = "688cc9a4dac77052a7a67f76"
        # (3 unchanged attributes hidden)
    }


Plan: 1 to add, 3 to change, 1 to destroy.

In case the plan shows different planned actions, stop and revisit previous steps. Moving the state incorrectly, or omitting steps will result in a major disruption, as entire site specific configuration of the schema will be removed from both NDO and APIC, and will need to be reconfigured.