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

Add support for user defined interface role #2456

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

Originally created by @dgarros on GitHub (Mar 13, 2019).

Environment

  • Python version: 3.6
  • NetBox version: 2.5.7

Proposed Functionality

The proposal is to add support for use defined interface role in a similar fashion than what netbox supports today for

  • device roles
  • prefix/vlan roles
  • rack roles

I thought this had already been proposed but I couldn't find a similar proposal so I figured it might be a good idea to restart the conversation.

Use Case

The use case for this feature is to be able to clearly identify the role of an interface (uplink, backbone, peer_peer etc.. ). It would be very useful both in the UI and when we are pulling the data from the API to integrate with our monitoring solution.
in our environment the role of an interface is critical and we derive a lot of information from it, we alert differently on a uplink than we alert on a server facing interface etc ..

I thought about using a tag but since the tags are free form and they don't have a key/value approach it makes it harder to parse and rely on from my experience.

Database Changes

my guess would be

  • Add new table for interface_role
  • Add foreign key in the interface table to the interface_role table

External Dependencies

Originally created by @dgarros on GitHub (Mar 13, 2019). ### Environment * Python version: 3.6 * NetBox version: 2.5.7 ### Proposed Functionality The proposal is to add support for use defined interface role in a similar fashion than what netbox supports today for - device roles - prefix/vlan roles - rack roles I thought this had already been proposed but I couldn't find a similar proposal so I figured it might be a good idea to restart the conversation. ### Use Case The use case for this feature is to be able to clearly identify the role of an interface (uplink, backbone, peer_peer etc.. ). It would be very useful both in the UI and when we are pulling the data from the API to integrate with our monitoring solution. in our environment the role of an interface is critical and we derive a lot of information from it, we alert differently on a uplink than we alert on a server facing interface etc .. I thought about using a tag but since the tags are free form and they don't have a key/value approach it makes it harder to parse and rely on from my experience. ### Database Changes my guess would be - Add new table for interface_role - Add foreign key in the interface table to the interface_role table ### External Dependencies
adam closed this issue 2025-12-29 18:19:00 +01:00
adam commented 2025-12-29 18:19:00 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 13, 2019):

This is a common use case for tags.

I thought about using a tag but since the tags are free form and they don't have a key/value approach it makes it harder to parse and rely on from my experience.

I don't see how parsing them would be significantly different. A role would be something like:

if interface['role']['label'] == 'Backbone':

whereas a tag would be:

if 'Backbone' in interface['tags']:

In fact tags have a distinct advantage in that you can assign multiple tags to the same object.

@jeremystretch commented on GitHub (Mar 13, 2019): This is a common use case for tags. > I thought about using a tag but since the tags are free form and they don't have a key/value approach it makes it harder to parse and rely on from my experience. I don't see how parsing them would be significantly different. A role would be something like: ``` if interface['role']['label'] == 'Backbone': ``` whereas a tag would be: ``` if 'Backbone' in interface['tags']: ``` In fact tags have a distinct advantage in that you can assign multiple tags to the same object.
adam commented 2025-12-29 18:19:01 +01:00
Author
Owner
Copy Link

@dgarros commented on GitHub (Mar 13, 2019):

I understand you could make it work but based on my experience it would be better if the role is clearly identified and if you can ensure that only one role is defined for a given interface.

If you have multiple tags, how do you know for sure which one identify the role ? what if someone made a type while defining the tag ? Also if you introduce a new role (using tags) you'll have to update some code to take that into consideration whether if the role is clearly identified with its own field there is no guessing.

I think it's great to have tags on a lot of objects now but they might not be the best solution to every problem.

@dgarros commented on GitHub (Mar 13, 2019): I understand you could make it work but based on my experience it would be better if the role is clearly identified and if you can ensure that only one role is defined for a given interface. If you have multiple tags, how do you know for sure which one identify the role ? what if someone made a type while defining the tag ? Also if you introduce a new role (using tags) you'll have to update some code to take that into consideration whether if the role is clearly identified with its own field there is no guessing. I think it's great to have tags on a lot of objects now but they might not be the best solution to every problem.
adam commented 2025-12-29 18:19:01 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Mar 14, 2019):

My take on this is that it is actually relevant to the data model of an Interface in the grand scheme of things.

I agree that from a pure programmatic mindset, tags fit the bill just fine, but I feel this type of use case highlights the contrast between the meaningfulness of what NetBox is supposed to do at its core and the usefulness of tags. In this specific case, tags just seem inappropriate in place of a dedicated field.

Allowing for a finite set of values while protecting against fat-fingering of new tags seems optimal. I don't mean to diminish the point of tags, but I think they serve a different purpose here.

I also think there is a corollary to custom fields for interfaces in that I think an "interface role" is potentially one of the single largest use cases out there, whether people realize it today or not.

@lampwins commented on GitHub (Mar 14, 2019): My take on this is that it is actually relevant to the data model of an Interface in the grand scheme of things. I agree that from a pure programmatic mindset, tags fit the bill just fine, but I feel this type of use case highlights the contrast between the meaningfulness of what NetBox is supposed to do at its core and the usefulness of tags. In this specific case, tags just seem inappropriate in place of a dedicated field. Allowing for a finite set of values while protecting against fat-fingering of new tags seems optimal. I don't mean to diminish the point of tags, but I think they serve a different purpose here. I also think there is a corollary to custom fields for interfaces in that I think an "interface role" is potentially one of the single largest use cases out there, whether people realize it today or not.
adam commented 2025-12-29 18:19:01 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 14, 2019):

If you have multiple tags, how do you know for sure which one identify the role ?

A common practice is to use namespaces; something like role:uplink, role:access, etc.

what if someone made a type while defining the tag ?

What if someone typos the interface name? All free-form fields are prone to human error. Fortunately, the UI will auto-complete existing tags, and the complete list of tags is available for validation.

Also if you introduce a new role (using tags) you'll have to update some code to take that into consideration whether if the role is clearly identified with its own field there is no guessing.

Not sure what you're referring to; tags don't require any code changes. If you're talking about maintaining logic which integrates with NetBox, you would need to update it regardless to match on new tag/field values.

Again, I'm not seeing any justification for not using tags. This is a primary use case for why tags were implemented in the first place.

Further, if we were to add a role field to the Interface model, two things will inevitably happen:

  1. There will be an FR to change the field to support the assignment of multiple roles per interface, because it's a given that people will encounter a situation where roles overlap. And we'll have to abide, because by introducing the dedicated field, we're implying that tags should not be used for denoting role.

  2. There will be an FR to add the role field to other device components as well. And we'll have to, because if tags aren't sufficient to indicate functional role on interfaces, why would they be acceptable on other components?

All this work to essentially duplicate the functionality already provided by tags. Doesn't make sense to me.

@jeremystretch commented on GitHub (Mar 14, 2019): > If you have multiple tags, how do you know for sure which one identify the role ? A common practice is to use namespaces; something like `role:uplink`, `role:access`, etc. > what if someone made a type while defining the tag ? What if someone typos the interface name? All free-form fields are prone to human error. Fortunately, the UI will auto-complete existing tags, and the complete list of tags is available for validation. > Also if you introduce a new role (using tags) you'll have to update some code to take that into consideration whether if the role is clearly identified with its own field there is no guessing. Not sure what you're referring to; tags don't require any code changes. If you're talking about maintaining logic which integrates with NetBox, you would need to update it regardless to match on new tag/field values. Again, I'm not seeing any justification for not using tags. This is a primary use case for why tags were implemented in the first place. Further, if we were to add a `role` field to the Interface model, two things _will_ inevitably happen: 1. There will be an FR to change the field to support the assignment of multiple roles per interface, because it's a given that people will encounter a situation where roles overlap. And we'll have to abide, because by introducing the dedicated field, we're implying that tags should not be used for denoting role. 2. There will be an FR to add the role field to other device components as well. And we'll have to, because if tags aren't sufficient to indicate functional role on interfaces, why would they be acceptable on other components? All this work to essentially duplicate the functionality already provided by tags. Doesn't make sense to me.
adam commented 2025-12-29 18:19:01 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Jun 18, 2019):

About point 2 above: most things already seem to have a role. What makes interfaces different? Or are roles a historical accident and superseded by tags?

@steffann commented on GitHub (Jun 18, 2019): About point 2 above: most things already seem to have a role. What makes interfaces different? Or are roles a historical accident and superseded by tags?
adam commented 2025-12-29 18:19:01 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 15, 2019):

Closing this out as the use case can be satisfied by leveraging existing functionality.

@jeremystretch commented on GitHub (Oct 15, 2019): Closing this out as the use case can be satisfied by leveraging existing functionality.
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#2456
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?