Support Bridge-Interfaces in Interface-Template Import #20042
Description
NetBox version
v4.3.4
Feature type
Change to existing functionality
Proposed functionality
Issue #8272 respective PR #11869 added the possibility to "pre-bridge" interfaces (templates) in a device/module type, so any devices/modules created from it will already have on their interfaces the correct bridge interfaces set. This is useful for example when the hardware-device contains a hardware-network-switch with multiple built-in ports (both internal/cpu and external/physical).
While this feature already exists and works, it currently (as the PR also states) is not supported when importing device/module types. So when importing such a device/module type, you have to manually check and potentially adjust/correct the bridge configuration post-import.
This asymmetry between manually created and imported device types is especially impactful for the usage of device type libraries, both official/public and private, where you import a potentially large number of different device/module types. While the libraries can specify these bridge relations, that information is silently lost during the import into NetBox.
Unfortunately does the original PR not specify why exactly import is considered such a hard problem. For the simple cases where the bridge of an interface is in the same device/module type as the interface itself, it should be a simple ordering issue (create bridge first, then bridged interfaces). Edge-cases I can think of are circular (interface A is bridged by B, and interface B is bridged by A) and recursive (interface A is bridged by B, and interface C is bridged by B) bridge relationships.
Everything else (aka any cross-type-bridges) are impossible to safely model on the device/module type level, because you can't make any assumptions about the device/module composition the created instances may have.
I propose that when importing a device/module type, any of its interfaces can optionally have a bridge attribute, whose value is the name of the bridge interface as a string. If the attribute is not present, its value should be considered null. The values null and empty string mean "not set". Its value is subject to the same restrictions/constraints as the existing database/model field, most importantly that it can't be itself (an interface cannot be bridged to itself), and it must be an interface on the same device/module type (but not necessarily of type bridge). Failing to satisfy these data requirements will cause an error, reporting to the user an actionable message, and not create the device/module type or any of its components. When the import is successful, all created interface templates will have the bridge field set accordingly to the import-input-data.
I am willing to work on this. PR #13199 seems to be a nice reference since it does basically the same for rf_role, except I can skip (but still double-check) the changes to the database model. Any further hints or guidance is appreciated.
Use case
Device type libraries, both official/public and private, can properly document these built-in bridge relations. Consumers can simply import the device/module types in NetBox, without having to manually adjust/correct them post-import.
Database changes
No database change should be required, since the interface template already has all required fields.
External dependencies
No additional dependencies should be required.