Schema library for Infrahub
Welcome to the Schema Library for Infrahub! This repository offers a collection of schemas designed to streamline and standardize infrastructure-related data structures.
warning
This project is currently a collection of examples intended to serve as inspiration. Please note that it is in an experimental phase and may undergo significant changes.
Use case​
Infrahub ships without built-in schemas, giving you complete freedom to define your own. However, starting from scratch can be overwhelming, especially when many infrastructures share common models. That's where the Schema Library, maintained by OpsMill and the community, comes in.
The library provides a curated collection of practical, ready-to-use schemas designed to reflect real-world infrastructure needs. Use them out of the box, or treat them as a foundation: copy, adapt, and extend each schema to align precisely with your organization.
Project structure​
This project is divided into three main parts:
- Base: The foundational layer required for most extensions. It must be loaded before adding extensions.
- Extensions: Generic schema components for managing infrastructure. Extensions may have dependencies on each other.
- Experimental: Schema components that are not yet fully supported.
Getting started​
Clone the repository​
git clone https://github.com/opsmill/schema-library.git
cd schema-library
note
One of Infrahub's key strengths is its flexibility. We encourage you to copy any schemas you find useful into your own repository and tailor them to your specific needs, ensuring your schema aligns perfectly with your requirements.
How to load schemas​
There are two main ways to load schemas into Infrahub, depending on where you are in your Infrahub journey:
- Quick View: To quickly view a schema, you can use
infrahubctl. Please reference theinfrahubctlGuide for further instructions. - Controlled Integration: For a more organized and unified approach, you can connect a Git repository. Follow this guide to connect a Git repository.
note
For proof of concept or development purposes, using infrahubctl is the preferred approach. When running Infrahub in production, you might need the extra control provided by Git integration to load schemas.
Load schemas​
important
You need to load the base schema before loading any extensions. Extensions may have dependencies on each other, so you'll need to load them in the correct order.
# Load the base
infrahubctl schema load base
# Load an extension
infrahubctl schema load extensions/location_minimal
# Load another extension
infrahubctl schema load extensions/vlan
Available schemas​
This list provides an overview of the schemas available in this repository. Each schema is designed to address specific infrastructure needs, and you can find detailed documentation for each one by clicking its name.
base​
| Name | Description |
|---|---|
| DCIM | Base DCIM schema: device types, platforms, devices, and physical and virtual interfaces, plus the endpoint and connector generics that cables, circuits and cross-connects build on. |
| IPAM | Base IPAM schema: IP prefixes and IP addresses, plus the scope generics a prefix or a VLAN group can be attached to. |
| Location | Base Location schema: the generic every location tier inherits from, and the hosting generic that lets devices and other objects be placed at a location. Concrete tiers such as Site come from the location extensions. |
| Organization | Base Organization schema: the generic organization plus Manufacturer and Provider nodes. |
experimental​
| Name | Description |
|---|---|
| Azure | This schema extension introduces cloud support for Microsoft Azure. |
| Circuit Service | This schema extension contains model coming on top of circuit to capture a single service shared across multiple circuits. For example you have a MPLS network supported by a provider connecting multiple locations: - One single CircuitService would be needed to store MPLS related information (e.g. service id, provider ...) - On each site we would create a circuit connecting on one side our device and the CircuitService on the other side |
| Firewall Policer | This schema extension contains models for traffic policers and the classes and rules that reference them, so you can describe rate limiting alongside the interfaces it is applied to. |
| InfiniBand Fabric Hardware | This schema extension models the hardware of an InfiniBand fabric: switches with their configuration profile (AAA, role, split-ready, SSH and CLI settings), switch and management interfaces with lane width, split and speed options, rail-optimized scalable units (RSU) and the fabric that groups them. It does not model the InfiniBand protocol itself (subnet manager, partitions, routing). |
| Location Extended | This schema extension is the most detailed when it comes to location, you'll find all the layers you can think of. It defines its own hierarchical Location.Rack, incompatible with the flat one extensions/rack defines, so load one or the other, not both. |
| Modules Linecards | This schema extension allows you to capture Linecard related information like the version. You can insert the Linecard into a Dcim Physical Device and leverage the Linecard type model. The Linecard can accept PIC to help configure PORT information like breakout-capabilities and configurations. |
| Modules Routing Engine | This schema extension allows you to capture Routing Engine related information like the version. You can insert the Routing Engine into a Dcim Physical Device and leverage the Routing Engine type model. |
| Optical Transport | Comprehensive optical transport network schemas for DWDM/WDM systems (ADVA FSP 3000 and similar platforms). Covers four layers: wavelength (ITU-T G.694.1 grid, optical bands, DWDM channels), topology (logical optical nodes, passive multiplexers, fiber links), equipment (transponder/amplifier/ROADM modules, ROADM degrees, WSS cross-connects), and service (end-to-end optical services, optical paths, path segments). Not designed to be loaded together with extensions/optical_multiplexer. |
| QoS | This schema extension contains models for Quality of Service (QoS) |
| Security | This schema extension contains models for implementing detailed security. |
| Topology | A schema for defining and managing network topology, strategies, and services. |
| VLAN Translation | This schema extension is based on Juniper VLAN MAP, and not yet test out for other vendors. |
extensions​
| Name | Description |
|---|---|
| Cable | This schema extension contains a basic Cable model allowing you to connect two endpoints. |
| Circuit | This schema extension adds Circuit and Circuit Endpoint nodes and links them to your infrastructure. A circuit could be a fiber connecting two sites, with one endpoint on each site. |
| Circuit Contract | This schema extension adds a Circuit Contract node to capture the service agreement behind a circuit with its provider. |
| Cluster | This schema extension contains the foundations to capture clusters. With this one in place you can unlock various cluster flavours (a hosting cluster able to host VMs, a firewall cluster built with specific appliances ...). |
| Compute | This schema extension captures physical servers and virtual machines, with a generic compute unit both inherit from and a generic for anything able to host VMs. Pair it with extensions/hosting_cluster to group compute units into clusters. |
| Cross-Connect | This schema extension adds a Cross-Connect node. Think of it as a cable operated by a provider: attach it to a location, then connect endpoints to it (e.g. the rear interface of a patch panel or a circuit endpoint). |
| Device Module | This schema extension lets you capture module bays on a DcimPhysicalDevice and the modules installed into them (e.g. fan trays, line cards). A device can have any number of module bays, and each bay can optionally hold one module. It ships a ready-to-use Module and Module Type pair, plus the generic Module and Module Type you can build your own flavours on: see extensions/device_module_psu, or the experimental modules_linecards and modules_routing_engine extensions. |
| Hosting Cluster | A generic cluster built from compute units (e.g. servers) that can host virtual machines. |
| Interface Breakout | This schema extension introduces relationships to support breakout interfaces, enabling you to document the breakout of a physical interface into smaller physical interfaces. |
| Internet Exchange | This schema extension adds an Internet Exchange (IXP) node and an IXP Connection node linking your devices to an exchange, and ties IXP connections to the BGP sessions established over them. |
| IPAM Aggregate | This schema extension captures the top-level IPv4 and IPv6 blocks assigned by a Regional Internet Registry (RIR). It adds an Aggregate node for the block and an RIR node for the registry or private entity that manages the address space. |
| LAG | This schema extension includes models for Link Aggregation Groups (LAGs), enabling you to link physical interfaces as building blocks of your LAG interface. It can be used in standard networking environments as well as in compute scenarios, such as capturing bond interfaces. |
| Location Minimal | This schema extension provides a self-contained Region -> Country -> Metro -> Site hierarchy for storing location data, with the Site carrying facility, physical address, timezone and status. Its Site node is the same as the one in extensions/location_site, so the two can be loaded together. A location name is unique across every tier, so a single-country deployment should enter the hierarchy at Country, with Region as the national node, rather than repeating a country under several regions. |
| Location Site | This schema extension introduces a Site node with facility, physical address, timezone and status, for deployments that want a flat list of sites without a hierarchy. It is the same Site node as in extensions/location_minimal, which adds Region, Country and Metro tiers above it. |
| MLAG | This schema extension contains the foundations to capture Multi-Chassis Link Aggregation Groups (MLAG). It comes on top of the LAG extension. In this implementation, a MLAG interface is essentially a LAG interface but linked to a MLAG domain (instead of a device). The MLAG domain regroups devices together (usually 2) and is built over LAG interfaces used as peer-link between the devices. MLAG interfaces defined at the MLAG domain level are then spread across all devices in the domain. This is a deliberately minimal implementation of MLAG, meant to blend with models you already have. For example, in a data center fabric you might already have a LeafGroup or similar concept: have it inherit from GenericMlagDomain and add the relationships and attributes you need. Not covered yet: the layer 3 overlay for MLAG interfaces (loopback, peer address ...) and surfacing MLAG interfaces on each device in the domain. |
| Optical Multiplexer | This schema extension models optical add-drop multiplexers (OADM) and the wavelength division multiplexing (WDM) channels they carry, for both CWDM and DWDM. It adds an Optical Multiplexer device with front and rear interfaces, a WDM Channel node holding channel number, wavelength and frequency, and a WDM Transceiver flavour of the transceiver model tuned to a channel. Some vendors configure tunable optics by wavelength or frequency rather than channel number; the WDM Channel node gives you a single entry in Infrahub for all three. Not designed to be loaded together with experimental/optical_transport, which covers the same domain in more depth. |
| Patch Panel | This schema extension allows you to capture patch panel related information like rear and front interfaces and the mapping between them. You can insert the patch panel into a rack and leverage the device type model. Cassettes and other inserts are tracked as regular device modules in module bays, through extensions/device_module. The front and rear interfaces accept all sorts of connectors, so you can plug cables, circuits and cross-connects into them. |
| Physical Disk | Simple schema allowing you to capture physical disk information for inventory and lifecycle management. This extension works with any kind of device: apply the DcimDeviceWithPhysicalDisks generic to a model to enable disk tracking. You might also link disks to a location, for instance to capture spares. |
| PSU Module | This schema extension adds a PSU (Power Supply Unit) flavour on top of the generic Module and Module Type from extensions/device_module, so you can track power supplies installed in a device's module bays with PSU-specific attributes such as wattage and hot-swap capability. |
| QinQ | This schema extension adds the Service VLAN and Customer VLAN nodes needed to model QinQ on top of the VLAN extension. |
| Rack | This schema extension introduces a Rack node representing a physical equipment rack installed at a site. Racks are placed at a LocationSite, which comes from extensions/location_site or extensions/location_minimal, and can host devices and other equipment. experimental/location_extended defines its own Rack node, so do not load both. |
| Routing | This schema extension contains the Routing Protocol generic that every protocol extension builds on. The idea is one protocol instance per IpamVRF and DcimDevice pair. |
| Routing Aggregate | This schema extension adds an Aggregate Route node: a summary route, with its destination prefix and discard flag, announced by a routing protocol instance. |
| Routing BGP | This schema extension adds Autonomous System, BGP Peer Group and BGP Session nodes, and links autonomous systems to devices and organizations. |
| Routing BGP Community | This schema extension adds a BGP Community node to reference from routing policies. |
| Routing BGP Route Reflector | This schema extension adds a Route Reflector Cluster node on top of the BGP extension and links it to BGP peer groups. |
| Routing OSPF | This schema extension adds OSPF and OSPF Interface nodes to model an OSPF instance per device and VRF and the interfaces it runs on. |
| Routing PIM | This schema extension adds PIM (Protocol Independent Multicast) and PIM Interface nodes to model a PIM instance per device and VRF and the interfaces it runs on. |
| Routing Policies | This schema extension contains the Routing Policy generic. Each routing protocol extension subclasses it with its own policy flavour. |
| Routing Policies Aggregate | This schema extension adds an Aggregate Routing Policy node, a flavour of the Routing Policy generic, and replaces the free-text import and export policies on Aggregate Route with relationships to it. |
| Routing Policies BGP | This schema extension adds a BGP Routing Policy node, a flavour of the Routing Policy generic, and replaces the free-text import and export policies on BGP Peer Group and BGP Session with relationships to it. |
| Routing Policies OSPF | This schema extension adds an OSPF Routing Policy node, a flavour of the Routing Policy generic, and replaces the free-text import and export policies on OSPF with relationships to it. |
| Routing Policies PIM | This schema extension adds a PIM Routing Policy node, a flavour of the Routing Policy generic, and replaces the free-text import and export policies on PIM with relationships to it. |
| SNMP | This schema extension contains models for SNMP Communities and SNMP Clients. A community links to the devices it is configured on; any further wiring, to a tenant for instance, is left to you. |
| Tenancy | This schema extension introduces a Tenant node that can own devices, IP prefixes and addresses, and hosting locations. See the comment at the bottom of tenancy.yml for an example of how to extend tenancy onto optional extension nodes such as DcimCircuit. |
| Transceiver | This schema extension models pluggable transceivers across form factors (SFP, SFP+, QSFP, QSFP28, QSFP-DD, OSFP, CFP, XFP and more), with a Standard Transceiver and a Bidirectional Transceiver flavour built on a shared generic. A transceiver is either plugged into a physical interface or stored as a spare at a location, and can be linked to its manufacturer. Limitations: there is no validation between type, form factor, protocol and distance; any transceiver can be plugged into any physical interface; and nothing prevents a transceiver from being linked to both an interface and a spare location. |
| VLAN | This schema extension adds VLAN and VLAN Group nodes, with a generic VLAN to build on, and links VLANs to prefixes and layer 2 interfaces. |
| VRF | This schema extension adds VRF and Route Target nodes and links prefixes and IP addresses to a VRF. |
| VRRP | This schema extension adds VRRP Group and VRRP Interface nodes, linking a virtual IP address to the layer 3 interfaces that take part in the group. |
Troubleshooting​
Unable to load the schema: xxx unable to find the generic yyy- Missing requirements
This error indicates that the schema you are trying to load has dependencies on other schemas that are not present in your Infrahub instance.
success
To resolve this, ensure that you have loaded all required schemas before attempting to load the one in question. You can find the list of dependencies in the schema documentation.