OPCP - How the Ironic to NetBox synchronisation works

Als Markdown ansehen

Find out how OPCP nodes are imported from Ironic into NetBox and what the synchronisation keeps up to date

Objective

On an OVHcloud On-Prem Cloud Platform (OPCP), the physical and logical inventory shown in NetBox is not maintained by hand: it is populated automatically from OpenStack Ironic, which is the source of truth for the bare-metal nodes of your platform.

This guide explains how the Ironic to NetBox synchronisation works and what information it keeps up to date.

Info

The NetBox inventory is automatically populated from the OPCP control plane; no manual action is required to add, update, or remove nodes.

In OpenStack, a node corresponds to a physical server in the OPCP rack. In this guide, the term node therefore refers to a physical server.

Prerequisites

  • Being an administrator of the OPCP infrastructure and having access to the administration interface admin.dashboard.
  • Knowing how to access the NetBox inventory (see OPCP - How to see the node inventory).

Instructions

1. Overview of the synchronisation

The synchronisation runs automatically and reconciles the NetBox inventory with the current state of Ironic. On each run, it:

  1. Fetches the list of nodes and their network ports from Ironic.
  2. Creates or updates the matching devices in NetBox.
  3. Keeps interfaces, MAC addresses, and cabling to the switches in sync.
  4. Computes and updates the rack position of each node (see section 3).
  5. Decommissions devices that no longer exist in Ironic (see section 4).

Because NetBox is kept in sync with Ironic, it reflects the same reality as the OpenStack/Ironic view of your nodes. The node states described in OPCP - Node lifecycle are therefore mirrored into NetBox.

2. What the synchronisation imports

For each node, the synchronisation imports and keeps up to date:

  • Device identity: the device name, its site and rack.
  • Device type and manufacturer: derived from the node's hardware model and vendor reported by Ironic.
  • Identifiers: the Ironic node UUID is stored both as the device asset tag and in a dedicated baremetal_node_id field, so a NetBox device can always be mapped back to its Ironic node.
  • BMC information: the BMC MAC address and BMC address are stored on the device.
  • Status: mapped from the Ironic provision state.
  • Interfaces and MAC addresses: one interface per Ironic port, with its MAC address.
  • Cabling: cables between each node interface and the corresponding switch port, based on the link information reported by Ironic.
  • Rack position: the rack unit (U) of the node, when it can be determined (see section 3).

3. Rack position and elevation

The rack position imported by the synchronisation is what drives the rack elevation view in NetBox. The position is not entered by hand: it is computed from the node's cabling and from the position templates that OVHcloud provides for your rack type.

How the position is determined, when automatic placement applies, and when manual positioning is kept as a fallback are explained in detail in the OPCP - How to handle the NetBox rack elevation guide.

4. Decommissioning of removed nodes

When a node that previously existed in Ironic is no longer returned by Ironic, the synchronisation does not delete its device in NetBox. Instead, it:

  • sets the device status to Decommissioning;
  • clears its rack position and face, so it no longer appears in the rack elevation;
  • removes the cables attached to its interfaces.

This keeps a trace of the device in NetBox while making it clear that it is no longer part of the active inventory.

References

Go further

For training or technical assistance implementing our solutions, contact your sales representative or visit our Professional Services page to request a quote and have your project analysed by our experts.

Join our community of users.

War diese Seite hilfreich?