A Terraform module to configure Nexus Dashboard Orchestrator (NDO).
This module is part of the Cisco Nexus-as-Code project. Its goal is to allow users to instantiate network fabrics in minutes using an easy to use, opinionated data model. It takes away the complexity of having to deal with references, dependencies or loops. By completely separating data (defining variables) from logic (infrastructure declaration), it allows the user to focus on describing the intended configuration while using a set of maintained and tested Terraform Modules without the need to understand the low-level ACI object model. More information can be found here: https://cisco.com/go/nexusascode.
This module supports an inventory driven approach, where a complete NDO configuration or parts of it are either modeled in one or more YAML files or natively using Terraform variables.
There are six configuration sections which can be selectively enabled or disabled using module flags:
system: Manage system level configuration like bannerssites: Enable sites in NDOsite_connectivity: Manage Multi-Site connectivity configurationtenants: Configure tenants using NDOschemas: Configurations applied at the schema and template level (e.g., VRFs and Bridge Domains)deploy_templates: Automatically deploy templates
The full data model documentation is available here: https://developer.cisco.com/docs/nexus-as-code/#!data-model
The module currently supports only NDO version 3.7.
Configuring a Tenant using YAML:
ndo:
sites:
- name: APIC1
id: 1
apic_urls:
- "https://10.1.1.1"
tenants:
- name: NDO1
sites:
- name: APIC1module "tenant" {
source = "netascode/nac-ndo/mso"
version = ">= 0.7.0"
yaml_files = ["ndo.yaml"]
manage_sites = true
manage_tenants = true
}Configuring a Site using native HCL:
module "site" {
source = "netascode/nac-ndo/mso"
version = ">= 0.7.0"
model = {
ndo = {
sites = [
{
name = "APIC1"
id = 1
apic_urls = ["https://10.1.1.1"]
}
]
}
}
manage_sites = true
}Depending on the exact configuration, there might be issues with the NDO API returning errors due to concurrent operations. In this case one can use the parallelism=1 command line attribute to ensure all resource operations are executed in sequence.
$ terraform apply -parallelism=1Alternatively, an environment variable can be used as well.
$ export TF_CLI_ARGS_apply="-parallelism=1"| Name | Version |
|---|---|
| terraform | >= 1.4.0 |
| local | >= 2.3.0 |
| mso | = 1.2.2 |
| utils | >= 0.2.5 |
| Name | Description | Type | Default | Required |
|---|---|---|---|---|
| deploy_templates | Flag to indicate if templates should be deployed. | bool |
false |
no |
| manage_schemas | Flag to indicate if schemas should be managed. | bool |
false |
no |
| manage_site_connectivity | Flag to indicate if site connectivity be managed. | bool |
false |
no |
| manage_sites | Flag to indicate if sites should be managed. | bool |
false |
no |
| manage_system | Flag to indicate if system level configuration should be managed. | bool |
false |
no |
| manage_tenants | Flag to indicate if tenants be managed. | bool |
false |
no |
| managed_schemas | List of schema names to be managed. By default all schemas will be managed. | list(string) |
[] |
no |
| managed_tenants | List of tenant names to be managed. By default all tenants will be managed. | list(string) |
[] |
no |
| model | As an alternative to YAML files, a native Terraform data structure can be provided as well. | map(any) |
{} |
no |
| write_default_values_file | Write all default values to a YAML file. Value is a path pointing to the file to be created. | string |
"" |
no |
| yaml_directories | List of paths to YAML directories. | list(string) |
[] |
no |
| yaml_files | List of paths to YAML files. | list(string) |
[] |
no |
| Name | Description |
|---|---|
| default_values | All default values. |
| model | Full model. |
| Name | Version |
|---|---|
| local | >= 2.3.0 |
| mso | = 1.2.2 |
| utils | >= 0.2.5 |
No modules.