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

Interface field "bridged interface" is ambiguously named #6505

New Issue
Closed
opened 2025-12-29 19:41:42 +01:00 by adam · 4 comments
adam commented 2025-12-29 19:41:42 +01:00
Owner
Copy Link

Originally created by @klaernie on GitHub (May 23, 2022).

NetBox version

v3.2.3

Python version

3.9

Steps to Reproduce

View an interface edit screen
observe the field named "bridged interface"

Expected Behavior

according to the naming I would expect to enter interfaces that are being bridged by the interface currently being edited (aka: entering bridge members or bridge ports)

Observed Behavior

As I can only enter a single interface into the "bridged interface" I understand the data model implicitly as such, that the interface currently being edited becomes a bridge member / bridge port of the interface being entered.

Other remarks

What also confuses but could be done better is, that the "bridged interface" field allows interface of all types to be entered. On a logical level that doesn't make sense, as only bridges should be able to accept bridge ports, and for every other relationship between two interfaces there exists the generic "parent interface".

Originally created by @klaernie on GitHub (May 23, 2022). ### NetBox version v3.2.3 ### Python version 3.9 ### Steps to Reproduce View an interface edit screen observe the field named "bridged interface" ### Expected Behavior according to the naming I would expect to enter interfaces that are being bridged by the interface currently being edited (aka: entering bridge members or bridge ports) ### Observed Behavior As I can only enter a single interface into the "bridged interface" I understand the data model implicitly as such, that the interface currently being edited becomes a bridge member / bridge port of the interface being entered. --- ### Other remarks What also confuses but could be done better is, that the "bridged interface" field allows interface of all types to be entered. On a logical level that doesn't make sense, as only bridges should be able to accept bridge ports, and for every other relationship between two interfaces there exists the generic "parent interface".
adam closed this issue 2025-12-29 19:41:42 +01:00
adam commented 2025-12-29 19:41:42 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 24, 2022):

This seems quite clear to me. Why would you assume a field labeled "bridged interface" (singular) would point to multiple objects?

@jeremystretch commented on GitHub (May 24, 2022): This seems quite clear to me. Why would you assume a field labeled "bridged interface" (singular) would point to multiple objects?
adam commented 2025-12-29 19:41:43 +01:00
Author
Owner
Copy Link

@klaernie commented on GitHub (May 24, 2022):

This seems quite clear to me.

Which is very understandable - you, as a developer, have an understanding of the data model that no user-of-just-one-week can have. While you look at the interface and see the data model shine through, I can only take a look at the UI and infer the data model.

Why would you assume a field labeled "bridged interface" (singular) would point to multiple objects?

Because a "bridge" spans two points. So applying this logic it would mean this interface is one of the bridged points, and the interfaces being entered into the field would be other points - so no reference to the bridge at all.

If the label would be "bridge interface" it would be already a bit clearer.
But I could also assume somebody missed the plural-s on "interface".

I'd say a better wording would be:

  • "Bridge"
  • "bridge port of bridge"
  • "Assigned to bridge"
  • "bridge member of"

There is probably also another component: you as an english native speaker (presumably) have a different grasp of how the phrase can be interpreted, while I, as somebody who learned english in what you'd call high school, need to adhere to a tad stricter meaning of words and grammar. So having a phrase that says "bridged interface" in being parsed as "an interface (or interfaces) that is (or are) being bridged by this interface".

Now all this language fuzziness is complicated by the tooling one is used to. Some UIs like physical switches or systemd-networkd provide a workflow where you always enter the configuration context of an interface to assign this interface to a bridge. Other UIs like Proxmox or /etc/network/interfaces(5) assigns interfaces to bridges by specifying the list of members as an attribute of the bridge.

@klaernie commented on GitHub (May 24, 2022): > This seems quite clear to me. Which is very understandable - you, as a developer, have an understanding of the data model that no user-of-just-one-week can have. While you look at the interface and see the data model shine through, I can only take a look at the UI and infer the data model. > Why would you assume a field labeled "bridged interface" (singular) would point to multiple objects? Because a "bridge" spans two points. So applying this logic it would mean this interface is one of the bridged points, and the interfaces being entered into the field would be other points - so no reference to the bridge at all. If the label would be "bridge interface" it would be already a bit clearer. But I could also assume somebody missed the plural-s on "interface". I'd say a better wording would be: - "Bridge" - "bridge port of bridge" - "Assigned to bridge" - "bridge member of" There is probably also another component: you as an english native speaker (presumably) have a different grasp of how the phrase can be interpreted, while I, as somebody who learned english in what you'd call high school, need to adhere to a tad stricter meaning of words and grammar. So having a phrase that says "bridged interface" in being parsed as "an interface (or interfaces) that is (or are) being bridged by this interface". Now all this language fuzziness is complicated by the tooling one is used to. Some UIs like physical switches or systemd-networkd provide a workflow where you always enter the configuration context of an interface to assign this interface to a bridge. Other UIs like Proxmox or /etc/network/interfaces(5) assigns interfaces to bridges by specifying the list of members as an attribute of the bridge.
adam commented 2025-12-29 19:41:43 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 24, 2022):

"Bridged interface" means "the interface to which this is bridged," which, again, is accurate. Sorry but I'm not going to burn any more time on this.

@jeremystretch commented on GitHub (May 24, 2022): "Bridged interface" means "the interface to which this is bridged," which, again, is accurate. Sorry but I'm not going to burn any more time on this.
adam commented 2025-12-29 19:41:43 +01:00
Author
Owner
Copy Link

@klaernie commented on GitHub (May 24, 2022):

@jeremystretch I'm sorry that you feel my issue is wasting your time. I know firsthand that maintaining a large project like this is a lot of work, and often is a very thankless job with loads of pointless pressure put upon you.

So thank you for building a tool that makes my life easier and I wouldn't have ever had the time to do.

But I also wanted to let you know, that your last phrase did not sit well with me, but rather is quite an emotional punch in the gut.

All the best to you,
Andre

@klaernie commented on GitHub (May 24, 2022): @jeremystretch I'm sorry that you feel my issue is wasting your time. I know firsthand that maintaining a large project like this is a lot of work, and often is a very thankless job with loads of pointless pressure put upon you. So thank you for building a tool that makes my life easier and I wouldn't have ever had the time to do. But I also wanted to let you know, that your last phrase did not sit well with me, but rather is quite an emotional punch in the gut. All the best to you, Andre
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
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#6505
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?