DcimDeviceType updates to show full device specs

[ryanmerolle]

Currently the DcimDeviceType objects do not show the full specs of a device model like you can see in NetBox or Nautobot. We should look to add those actual specs including interfaces, components, and other data you can find in https://github.com/netbox-community/devicetype-library. I can see this as especially useful when trying to quickly browse the catalog of devices and determining what device type to deploy.

Though DcimDeviceType have have templates associated to them based on role, those templates do not have to have to adhere to the physical DcimDeviceType specs. I will raise an infrahub feature request so that templates can be validated against their derived type.

[petercrocker]

From what I can understand above, there's two points you're making:

• It would be useful to have a library of vendor devices, similar to the NetBox library
• There's an issue around validation of templates to schema objects? (not clear on this one)

Infrahub uses templates to accomplish the first: https://github.com/opsmill/infrahub-bundle-dc/blob/main/objects/bootstrap/06_device_types.yml

It's often advantageous to define different templates for the same physical device. One example: the same 48 port specific switch model from a vendor could act as a leaf, a border leaf or a spine depending on it's role, and have very different template settings due to it's role.

Different deployments have different needs for granularity of detail. One deployment may want a server defined just to the level of serial number and physical ethernet ports. Another may care about PCI slots and when there's a GPU in slot 2. One benefit of Infrahub is that you're not forced to having too much schema or data you don't care about if it adds no value in your use cases.

In practice, the templates can be ported from existing models (like the NetBox library) or created with little effort.

As for the issue/feature you mentioned above, it would be helpful to get a bit more detail to understand the issue.

[ryanmerolle]

Thanks for the feedback, Pete. To clarify the two feature requests:

1. DeviceType as a "Digital Spec Sheet"
Beyond just configuration, in Netbox, Nautobot, and Device42 users often rely on the DeviceType model to serve as a single source of truth for the physical hardware specifications (e.g., generating a precise Bill of Materials). We need a way to model the immutable, advertised specs of the hardware (interfaces, components, etc.) that exists independently of how the device is logically deployed.

2. Inheritance & Validation of Physical Constraints
Ideally, non-customizable hardware constraints defined on the DeviceType should be automatically inherited by the Device or Template.

• Goal: Reduce redundancy and error.
• Example: If a switch model's physical ports 1-48 are strictly QSFP (supporting only 1G/10G/40G), the template should either auto-populate this or validate against it, ensuring we don't accidentally assign an unsupported speed or transceiver type in the configuration.

Great discussion. This is so much easier to have a discussion about Infrahub features given the quality of data modeling and data in this repo