Config Manager OverviewGetting Started with Nautobot

Nautobot Bootstrap Data Reference

View as Markdown

This document provides a comprehensive reference for the YAML schema types used to populate Nautobot with baseline Config Manager data. The LoadBootstrapData job (located in jobs/load_bootstrap_data.py) processes these YAML files in a specific dependency order to create manufacturers, device types, platforms, roles, tags, statuses, locations, tenants, namespaces, relationships, and config contexts in Nautobot.

The bootstrap data files are located in the data/ directory and are organized by schema type. The job supports deployment type filtering using the NV_CONFIG_MANAGER_DEPLOYMENT_TYPE environment variable, allowing different data sets to be loaded for different deployment scenarios (for example, superpod, a site-specific label, or all).

Loading Order and Dependencies

The LoadBootstrapData job processes schemas in the following order to ensure dependencies are satisfied:

OrderSchema TypeDependenciesNotes
1ManufacturersNoneBase dependency for device types and platforms
2TenantsNoneUsed by locations
3Location TypesNone (but can reference parent location types)Must define parents before children
4LocationsLocation Types, Statuses, TenantsStatus defaults to “Active” if not found
5NamespacesNoneUsed by IP objects
6StatusesNoneUsed by locations and other objects
7RolesNoneUsed by config contexts
8TagsNoneApplied to various objects
9PlatformsManufacturers (optional)Manufacturer must exist if specified
10Device TypesManufacturersManufacturer directory must exist
11RelationshipsContent TypesContent types must exist in Nautobot
12Config ContextsRoles, PlatformsRoles and platforms must exist if specified

Notes:

  • Manufacturers must be loaded first as they are required by Device Types and optionally by Platforms
  • Location Types should define parent types before child types in the YAML file
  • Locations are sorted by hierarchy (Provider → Region → Site → Module) before processing
  • Statuses should include “Active” as it is the default for locations
  • Roles and Platforms must exist before Config Contexts that reference them
  • Missing dependencies result in warnings, and the item is skipped (except for required fields which cause errors)

About the Data

You must populate several key data structures to make Config Manager work.

Devices / Device Types / Device Roles / Interfaces

Devices are the fundamental unit of configuration. They are the items you rack and configure, and in Config Manager, that usually means network switches. Device records contain hostnames, primary IPv4 addresses, and critical identifying attributes like MAC addresses and serial numbers. Create these operational records through the Nautobot UI, Nautobot API, bulk import, migration scripts, or Design Builder topology jobs so provisioning and rendering know which device gets what.

Device Types are the manufacturer’s model of what you are deploying. For example, NVIDIA SN5600.

Device Roles define the function of an individual Device. The Role of a Device defines much of the base template applied by the Config Manager system, so this can be considered the base unit of Config Manager deployment. Examples may include “access-switch,” “TOR,” or “Spine.”

Interfaces are physical device ports, for things like Ethernet, Infiniband, BMC, and so on. These connect to Cables and link to IP addresses. There are also logical interface types, like VLAN Interfaces or Loopbacks. These connect to IP addresses, but not Cables.

Racks / Cables / Location Types / Locations

Racks are where you rack your gear, and how you tell your datacenter operators where to put things.

Cables define how you connect devices together. The full set of cables in your data set will be used to validate that the deployment has been properly cabled and powered up, in the Cable Validation workflow. Populating this precisely will help you bring up your fleet quickly and get accurate reports on any problems you need to fix.

Location Types define the generic hierarchy of how your locations fit together. For example, Regions may be at your top level, with Sites nested under those, and perhaps Modules below that. At minimum, most operators likely want a Site Location Type.

Locations are instances of Location Types. Racks belong to Locations.

Prefixes, IP Addresses, VLANs

IPAM objects need to be populated and applied to Devices or Location objects respectively, to establish connectivity and routing for Devices.

Common Schema Patterns

Deployment Type Filtering

Most schema types support a deployment_types field that controls when an item is loaded:

  • Type: Array of strings or single string
  • Default: ["all"] if not specified
  • Values: Common values include all, superpod, or site-specific labels you define
  • Behavior: Item is loaded if NV_CONFIG_MANAGER_DEPLOYMENT_TYPE matches any value in the array, or if all is in the array

Example:

1deployment_types: [all, superpod]
2# or
3deployment_types: superpod

Content Types

Roles, tags, and statuses can specify which Nautobot content types they apply to using the content_types field:

  • Type: Array of strings
  • Format: {app_label}.{model} (for example, dcim.device, dcim.interface, ipam.prefix)
  • Common Content Types:
    • dcim.device - Devices
    • dcim.interface - Interfaces
    • ipam.prefix - IP Prefixes
    • ipam.ipaddress - IP Addresses
    • ipam.vlan - VLANs
    • ipam.vrf - VRFs
    • circuits.circuit - Circuits

Hierarchical References

Some schemas support parent relationships using either:

  1. String format: Simple parent name lookup

    1parent: NVIDIA

  2. Dictionary format: Nested lookup with multiple criteria

    1parent:
    2  name: IPP5_Mississippi
    3  parent__name: AMER
    4  parent__parent__name: NVIDIA

Field Naming Conventions

  • Field names use lowercase with underscores (snake_case)
  • Required fields are typically name or model
  • Optional fields often have sensible defaults
  • Boolean fields default to true when not specified

Schema Reference

1. Manufacturers

File Location: data/manufacturers.yaml

Description: Network equipment vendors, server manufacturers, and infrastructure providers.

Required Fields

FieldTypeDescription
namestringManufacturer name (must be unique)

Optional Fields

FieldTypeDefaultDescription
descriptionstring""Description of the manufacturer
deployment_typesarray/string["all"]Deployment types this manufacturer applies to

Relationships

  • Used by: Device Types (by directory structure), Platforms

Example

1---
2# Network Equipment Vendors
3- name: NVIDIA
4  description: NVIDIA networking switches and systems
5  deployment_types: [all, superpod]
6
7- name: Mellanox
8  description: Mellanox networking equipment (now NVIDIA)
9  deployment_types: [all, superpod]
10
11- name: Arista
12  description: Arista ethernet switches
13  deployment_types: [all, superpod]

Notes

  • Manufacturer names must match directory names in data/device_types/ for device types to be associated correctly.
  • The job uses a get_or_create upsert method, so existing manufacturers are not overwritten.

2. Device Types

File Location: data/device_types/{manufacturer}/*.yaml

Description: Physical device models organized by manufacturer in subdirectories.

Required Fields

FieldTypeDescription
modelstringDevice model name
manufacturerstringManufacturer name (must match directory name)

Optional Fields

FieldTypeDefaultDescription
part_numberstring""Part number
u_heightinteger1Rack unit height
is_full_depthbooleantrueWhether device is full depth
weightfloat-Device weight
weight_unitstring-Weight unit (such as kg)
commentsstring-Additional comments (supports markdown)
device_familystring-Device family classification
deployment_typesarray/string["all"]Deployment types this device type applies to
console_portsarray-List of console port definitions
power_portsarray-List of power port definitions
interfacesarray-List of interface definitions
module_baysarray-List of module bay definitions

Console Ports Structure

1console_ports:
2  - name: con0
3    type: rj-45

Power Ports Structure

1power_ports:
2  - name: PSU1
3    type: iec-60320-c14
4    maximum_draw: 150

Interfaces Structure

1interfaces:
2  - name: eth0
3    type: 1000base-t
4    mgmt_only: true
5  - name: swp[1-48]
6    type: 1000base-t

Module Bays Structure

1module_bays:
2  - name: qsfp[1-4]
3    label: QSFP28 slot [1-4]
4    description: 100gbase-x-qsfp28
5    position: "[1-4]"

Relationships

  • Requires: Manufacturer (must exist)
  • Used by: Devices created through the Nautobot UI, Nautobot API, bulk import, migration scripts, or Design Builder topology jobs

Example

1---
2manufacturer: NVIDIA
3model: SN2201
4part_number: SN2201
5device_family: Network
6u_height: 1
7is_full_depth: false
8weight: 7.4
9weight_unit: kg
10comments: "[Data Sheet](https://docs.nvidia.com/networking/display/sn2000pub/)"
11deployment_types: [all, superpod]
12console_ports:
13  - name: con0
14    type: rj-45
15power_ports:
16  - name: PSU1
17    type: iec-60320-c14
18    maximum_draw: 150
19  - name: PSU2
20    type: iec-60320-c14
21    maximum_draw: 150
22interfaces:
23  - name: eth0
24    type: 1000base-t
25    mgmt_only: true
26  - name: swp[1-48]
27    type: 1000base-t
28module_bays:
29  - name: qsfp[1-4]
30    label: QSFP28 slot [1-4]
31    description: 100gbase-x-qsfp28
32    position: "[1-4]"

Notes

  • Device type files must be placed in a subdirectory matching the manufacturer name
  • Interface names can use bracket notation for ranges (for example, swp[1-48])
  • The manufacturer field in the YAML must match the directory name
  • Only model, part_number, u_height, and is_full_depth are stored in Nautobot; other fields are informational

3. Platforms

File Location: data/platforms.yaml

Description: Network operating systems and software platforms that run on devices.

Required Fields

FieldTypeDescription
namestringPlatform name (must be unique)

Optional Fields

FieldTypeDefaultDescription
manufacturerstring-Associated manufacturer name
descriptionstring""Platform description
deployment_typesarray/string["all"]Deployment types this platform applies to

Relationships

  • Requires: Manufacturer (optional, but must exist if specified)
  • Used by: Config Contexts, Devices

Example

1---
2# Network OS Platforms for Config Manager deployments
3
4- name: Arista EOS
5  manufacturer: Arista
6  description: ""
7
8- name: Cumulus Linux
9  manufacturer: NVIDIA
10  description: ""
11
12- name: MLNX-OS
13  manufacturer: Mellanox
14  description: ""
15
16- name: NV-OS
17  manufacturer: NVIDIA
18  description: ""

Notes

  • If manufacturer is specified, it must exist in the manufacturers list.
  • Platforms are created with a get_or_create upsert method, so existing platforms are not overwritten

4. Roles

File Location: data/roles.yaml

Description: Functional roles assigned to devices and interfaces to categorize their purpose in the network.

Required Fields

FieldTypeDescription
namestringRole name (must be unique)

Optional Fields

FieldTypeDefaultDescription
descriptionstring-Role description
colorstringgreyHex color code (without #) or name of a Nautobot color
weightinteger-Display weight/priority
content_typesarray-List of content types this role applies to (for example, ["dcim.device", "dcim.interface"])
deployment_typesarray/string["all"]Deployment types this role applies to

Relationships

  • Used by: Config Contexts (using the roles field), Devices, Interfaces

Example

1---
2# Device and Interface Roles for Config Manager Superpod deployments
3
4- name: superpod-spine
5  description: Superpod spine switch
6  content_types:
7    - dcim.device
8  color: 2196f3
9  deployment_types: [all, superpod]
10
11- name: superpod-computeleaf
12  description: Superpod compute leaf switch
13  content_types:
14    - dcim.device
15  color: 2196f3
16  deployment_types: [all, superpod]
17
18- name: Uplink
19  description: Uplink interface
20  content_types:
21    - dcim.interface
22  color: 2196f3
23  deployment_types: [all, superpod]

Notes

  • The content_types field must be set for both new and existing roles.
  • Content type format is {app_label}.{model} (for example, dcim.device).
  • Roles are created with a get_or_create upsert method, but content_types are always updated.

5. Tags

File Location: data/tags.yaml

Description: Labels used to categorize and filter devices, interfaces, and other objects.

Required Fields

FieldTypeDescription
namestringTag name (must be unique)

Optional Fields

FieldTypeDefaultDescription
descriptionstring""Tag description
colorstring9e9e9eHex color code (without #) or name of a Nautobot color
content_typesarray-List of content types this tag applies to
deployment_typesarray/string["all"]Deployment types this tag applies to

Relationships

  • Used by: Any object type specified in content_types

Example

1---
2# Tags for Config Manager deployments
3
4- name: dns-exempt
5  description: Interfaces exempt from DNS registration
6  color: c0c0c0
7  content_types:
8    - dcim.interface
9  deployment_types: [all, superpod]
10
11- name: spectrumx
12  description: Spectrum-X namespace tag for VPC workflows
13  color: 9e9e9e
14  content_types:
15    - ipam.namespace
16    - ipam.vrf
17  deployment_types: [all, superpod]

Notes

  • Tags use update_or_create, so color and description are always updated
  • content_types must be set for both new and existing tags
  • Tags are commonly used for automation workflows and filtering

6. Statuses

File Location: data/statuses.yaml

Description: Operational states for devices, interfaces, IP addresses, and other objects.

Required Fields

FieldTypeDescription
namestringStatus name (must be unique)

Optional Fields

FieldTypeDefaultDescription
descriptionstring""Status description
colorstring9e9e9eHex color code (without #) or name of a Nautobot color
content_typesarray-List of content types this status applies to
deployment_typesarray/string["all"]Deployment types this status applies to

Relationships

  • Used by: Locations (defaults to “Active” if not specified), Devices, Interfaces, IP objects

Example

1---
2# Statuses for Config Manager deployments
3
4- name: Active
5  description: Active/operational status
6  color: 4caf50
7  content_types:
8    - dcim.device
9    - dcim.interface
10    - ipam.ipaddress
11    - ipam.prefix
12    - ipam.vlan
13    - ipam.vrf
14    - circuits.circuit
15  deployment_types: [all, superpod]
16
17- name: Planned
18  description: Planned but not yet deployed
19  color: 00bcd4
20  content_types:
21    - dcim.device
22    - dcim.interface
23    - ipam.ipaddress
24    - ipam.prefix
25    - ipam.vlan
26    - ipam.vrf
27    - circuits.circuit
28  deployment_types: [all, superpod]
29
30- name: Maintenance
31  description: Under maintenance
32  color: ff9800
33  content_types:
34    - dcim.device
35    - dcim.interface
36  deployment_types: [all, superpod]

Notes

  • Statuses use update_or_create, so color and description are always updated
  • content_types must be set for both new and existing statuses
  • Locations default to “Active” status if not specified or if the specified status does not exist

7. Location Types

File Location: data/location_types.yaml

Description: Hierarchical types that define the structure of physical locations (for example, Provider → Region → Site → Module).

Required Fields

FieldTypeDescription
namestringLocation type name (must be unique)

Optional Fields

FieldTypeDefaultDescription
descriptionstring""Location type description
nestablebooleantrueWhether locations of this type can contain other locations
parentstring-Parent location type name (must exist)
deployment_typesarray/string["all"]Deployment types this location type applies to

Relationships

  • Requires: Parent Location Type (optional, but must exist if specified)
  • Used by: Locations

Example

1---
2# Location types for Config Manager hierarchical locations
3
4- name: Provider
5  description: Service provider or organization
6  nestable: true
7  deployment_types: [all, superpod]
8
9- name: Region
10  description: Geographic region
11  parent: Provider
12  nestable: true
13  deployment_types: [all, superpod]
14
15- name: Site
16  description: Physical datacenter site
17  parent: Region
18  nestable: true
19  deployment_types: [all, superpod]
20
21- name: Module
22  description: Module or pod within a site
23  parent: Site
24  nestable: false
25  deployment_types: [all, superpod]

Notes

  • Location types form a hierarchy using the parent field
  • Parent location types must be defined before child types
  • The nestable field controls whether locations of this type can contain other locations

8. Locations

File Location: data/locations.yaml

Description: Physical location instances organized in a hierarchical structure.

Required Fields

FieldTypeDescription
namestringLocation name
location_typestringLocation type name (must exist)

Optional Fields

FieldTypeDefaultDescription
parentstring/dict-Parent location (string name or dict with lookup criteria)
statusstringActiveStatus name (must exist)
tenantstring-Tenant name (must exist if specified)
descriptionstring""Location description
deployment_typesarray/string["all"]Deployment types this location applies to

Parent Reference Formats

String format (simple name lookup):

1parent: NVIDIA

Dictionary format (nested lookup):

1parent:
2  name: IPP5_Mississippi
3  parent__name: AMER
4  parent__parent__name: NVIDIA

Relationships

  • Requires: Location Type (must exist), Status (defaults to “Active”), Tenant (optional), Parent Location (optional)
  • Used by: Devices, Racks, Circuits

Example

1---
2# Location instances for Config Manager deployments
3# Hierarchical structure: Provider > Region > Site > Module
4
5- name: NVIDIA
6  location_type: Provider
7  status: Active
8  description: NVIDIA Corporation
9  deployment_types: [all, superpod]
10
11- name: AMER
12  parent: NVIDIA
13  location_type: Region
14  status: Active
15  tenant: Superpod
16  description: Americas region
17  deployment_types: [all, superpod]
18
19- name: IPP5_Mississippi
20  parent:
21    name: AMER
22    parent__name: NVIDIA
23  location_type: Site
24  status: Active
25  tenant: Superpod
26  description: Mississippi datacenter site
27  deployment_types: [all, superpod]
28
29- name: MISSISSIPPI SUPERPOD 1
30  parent:
31    name: IPP5_Mississippi
32    parent__name: AMER
33    parent__parent__name: NVIDIA
34  location_type: Module
35  status: Active
36  tenant: Superpod
37  description: Mississippi superpod module 1
38  deployment_types: [all, superpod]

Notes

  • Locations are processed in hierarchy order (Provider → Region → Site → Module) to ensure parents exist before children
  • If parent lookup fails, the location is created without a parent
  • If tenant lookup fails, the location is created without a tenant
  • Locations use update_or_create based on name and location_type

9. Tenants

File Location: data/tenants.yaml

Description: Organizational tenants for grouping and isolating resources.

Required Fields

FieldTypeDescription
namestringTenant name (must be unique)

Optional Fields

FieldTypeDefaultDescription
descriptionstring""Tenant description
deployment_typesarray/string["all"]Deployment types this tenant applies to

Relationships

  • Used by: Locations, Devices, IP Addresses, Prefixes, VLANs, VRFs

Example

1---
2# Tenants for Config Manager deployments
3
4- name: NGC
5  description: NVIDIA GPU Cloud tenant for superpod devices
6  deployment_types: [all, superpod]
7
8- name: Superpod
9  description: Superpod tenant for infrastructure devices
10  deployment_types: [all, superpod]

Notes

  • Tenants are created with a get_or_create upsert method, so existing tenants are not overwritten.
  • Tenants are commonly used for multi-tenant isolation.

10. Namespaces

File Location: data/namespaces.yaml

Description: IP address and VLAN namespaces for organizing network addressing.

Required Fields

FieldTypeDescription
namestringNamespace name (must be unique)

Optional Fields

FieldTypeDefaultDescription
descriptionstring""Namespace description
deployment_typesarray/string["all"]Deployment types this namespace applies to

Relationships

  • Used by: IP Addresses, Prefixes, VLANs, VRFs

Example

1---
2# IP/VLAN Namespaces for Config Manager deployments
3
4- name: Global
5  description: Global namespace for IP addresses and VLANs
6  deployment_types: [all, superpod]
7
8- name: Superpod
9  description: Superpod namespace for IP addresses and VLANs
10  deployment_types: [all, superpod]

Notes

  • Namespaces are created with a get_or_create upsert method, so existing namespaces are not overwritten.
  • Namespaces provide logical separation of IP addressing schemes.

11. Relationships

File Location: data/relationships.yaml

Description: Custom relationships between different object types in Nautobot.

Required Fields

FieldTypeDescription
namestringRelationship name (for reference)
labelstringRelationship label (used as unique identifier)
source_typestringSource content type (format: {app_label}.{model})
destination_typestringDestination content type (format: {app_label}.{model})

Optional Fields

FieldTypeDefaultDescription
descriptionstring""Relationship description
typestringone-to-manyRelationship type: one-to-one, one-to-many, or many-to-many
source_labelstring""Label for source side of relationship
destination_labelstring""Label for destination side of relationship
destination_hiddenboolean-Whether destination side is hidden in UI
required_onstringneitherWhere relationship is required: neither, source, destination, or both
deployment_typesarray/string["all"]Deployment types this relationship applies to

Relationships

  • Requires: Source and destination content types must exist in Nautobot

Example

1---
2# Relationships for Config Manager deployments
3
4- name: prefix-to-gateway
5  label: prefix-to-gateway
6  description: Prefix to Gateway Relationship
7  type: one-to-one
8  source_type: ipam.prefix
9  source_label: Gateway
10  destination_type: ipam.ipaddress
11  destination_label: Gateway for Prefix
12  destination_hidden: true
13  required_on: neither
14  deployment_types: [all, superpod]

Notes

  • Relationships use a update_or_create upsert method based on label, so existing relationships are updated.
  • Content types must be valid Nautobot content types (for example, dcim.device, ipam.prefix).
  • The name field is for reference only; label is the unique identifier.

12. Config Contexts

File Location: data/config_contexts.yaml

Description: JSON data structures applied to devices based on roles and platforms for configuration management.

Required Fields

FieldTypeDescription
namestringConfig context name (must be unique)

Optional Fields

FieldTypeDefaultDescription
descriptionstring""Config context description
weightinteger1000Priority weight (lower = higher priority)
is_activebooleantrueWhether context is active
dataobject{}JSON data structure to apply
rolesarray-List of role names to apply this context to
platformsarray-List of platform names to apply this context to
deployment_typesarray/string["all"]Deployment types this config context applies to

Relationships

  • Requires: Roles and Platforms (must exist if specified in roles or platforms arrays)
  • Used by: Devices (matched by role and/or platform)

Example

1---
2# Global Config Contexts for Config Manager deployments
3
4- name: Cumulus Linux Password Mappings
5  description: Default password mappings for Cumulus Linux devices
6  weight: 1000
7  is_active: true
8  roles:
9    - superpod-spine
10    - Superpod TOR
11    - Superpod StorageLeaf
12    - Superpod PowerLeaf
13    - Superpod ManagementLeaf
14    - Superpod OOBSpine
15    - superpod-borderleaf
16    - superpod-computeleaf
17  platforms:
18    - Cumulus Linux
19  data:
20    password_mappings:
21      default:
22        cumulus:
23          password: root_password
24          rotation: r1
25  deployment_types: [all, superpod]
26
27- name: Cumulus Linux Firmware 5.14.0
28  description: Intended firmware version for Cumulus Linux switches
29  weight: 1000
30  is_active: true
31  platforms:
32    - Cumulus Linux
33  data:
34    intended-firmware:
35      version: "5.14.0"
36  deployment_types: [all, superpod]

Notes

  • Config contexts use an update_or_create upsert method based on name, so existing contexts are updated.
  • If a role or platform in the roles or platforms array does not exist, it is skipped with a warning.
  • The data field contains arbitrary JSON that is merged into device configuration contexts.
  • Config contexts are applied to devices that match the specified roles and/or platforms.
  • Multiple config contexts can apply to the same device; they are merged by weight.