starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Support Bridge-Interfaces in Interface-Template Import #11455

New Issue
Open
opened 2025-12-29 21:45:26 +01:00 by adam · 2 comments
adam commented 2025-12-29 21:45:26 +01:00
Owner
Copy Link

Originally created by @m-hau on GitHub (Aug 7, 2025).

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.

Originally created by @m-hau on GitHub (Aug 7, 2025). ### 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. <hr> 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.
adam added the type: featurestatus: needs ownernetboxcomplexity: low labels 2025-12-29 21:45:26 +01:00
adam commented 2025-12-29 21:45:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 7, 2025):

Thanks @m-hau, I've assigned this to you.

@jeremystretch commented on GitHub (Aug 7, 2025): Thanks @m-hau, I've assigned this to you.
adam commented 2025-12-29 21:45:27 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 21, 2025):

Unfortunately we've had to decline PR #20082 due to the complex logic involved in validating the bridge assignments. I'll leave this open for now in case anyone comes up with a clever idea for a simpler solution.

@jeremystretch commented on GitHub (Oct 21, 2025): Unfortunately we've had to decline PR #20082 due to the complex logic involved in validating the bridge assignments. I'll leave this open for now in case anyone comes up with a clever idea for a simpler solution.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label complexity: low netbox status: needs owner type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#11455
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?