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

Allow the enabled field to be set on InterfaceTemplates #7480

New Issue
Closed
opened 2025-12-29 20:23:54 +01:00 by adam · 10 comments
adam commented 2025-12-29 20:23:54 +01:00
Owner
Copy Link

Originally created by @kkthxbye-code on GitHub (Jan 9, 2023).

Originally assigned to: @kkthxbye-code on GitHub.

NetBox version

v3.4.2

Feature type

Change to existing functionality

Proposed functionality

Allow the enabled field to be set on InterfaceTemplates added to DeviceTypes or ModuleTypes. The implementation would mirror the mgmt_only field which is currently supported.

Use case

DeviceTypes might be configured with disabled interfaces by default. In some cases ports might be configurable at different speeds depending on the installed SFP which changes the name of the interface on the device. Currently we have both combinations on the DeviceType, e.g.:

GigabitEthernet0/0/0/20
TenGigE0/0/0/20

Having the option to disabled one of the interfaces by default would help manage this.

Database changes

Add enabled BooleanField to InterfaceTemplate.

External dependencies

None

Originally created by @kkthxbye-code on GitHub (Jan 9, 2023). Originally assigned to: @kkthxbye-code on GitHub. ### NetBox version v3.4.2 ### Feature type Change to existing functionality ### Proposed functionality Allow the `enabled` field to be set on InterfaceTemplates added to `DeviceTypes` or `ModuleTypes`. The implementation would mirror the `mgmt_only` field which is currently supported. ### Use case DeviceTypes might be configured with disabled interfaces by default. In some cases ports might be configurable at different speeds depending on the installed SFP which changes the name of the interface on the device. Currently we have both combinations on the DeviceType, e.g.: GigabitEthernet0/0/0/20 TenGigE0/0/0/20 Having the option to disabled one of the interfaces by default would help manage this. ### Database changes Add `enabled` BooleanField to `InterfaceTemplate`. ### External dependencies None
adam added the status: acceptedtype: feature labels 2025-12-29 20:23:54 +01:00
adam closed this issue 2025-12-29 20:23:54 +01:00
adam commented 2025-12-29 20:23:55 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Jan 9, 2023):

I implemented it here to see if there were any hard stuff needing to be done, there wasn't.

https://github.com/netbox-community/netbox/compare/develop...kkthxbye-code:netbox:11440-add-enabled-interfacetemplate

If accepted, it might need to be targeted v3.5 as there's db and API changes, however existing DeviceTypes in the devicetype-library should be compatible as the enabled field defaults to True.

@kkthxbye-code commented on GitHub (Jan 9, 2023): I implemented it here to see if there were any hard stuff needing to be done, there wasn't. https://github.com/netbox-community/netbox/compare/develop...kkthxbye-code:netbox:11440-add-enabled-interfacetemplate If accepted, it might need to be targeted v3.5 as there's db and API changes, however existing DeviceTypes in the devicetype-library should be compatible as the enabled field defaults to True.
adam commented 2025-12-29 20:23:55 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Jan 9, 2023):

Why create two interfaces, and not rename the one interfaces ?
The slot/mod/port/forgotwhattheyare should be the identifiers...
I even tend to just put Eth0/0/0/20 in netbox, and forget about all the rest,,,

(also to tackle the interface naturalization sorting that messes some use cases up)

@PieterL75 commented on GitHub (Jan 9, 2023): Why create two interfaces, and not rename the one interfaces ? The slot/mod/port/forgotwhattheyare should be the identifiers... I even tend to just put Eth0/0/0/20 in netbox, and forget about all the rest,,, (also to tackle the interface naturalization sorting that messes some use cases up)
adam commented 2025-12-29 20:23:56 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Jan 9, 2023):

@PieterL75 - Our users prefer to have both interfaces and disable the one not being used. It also helps with custom scripts where the user has to choose an interface, as it allows both configurations to be shown and we can do the enabling of the chosen interface.

The slot/mod/port/forgotwhattheyare should be the identifiers...
I even tend to just put Eth0/0/0/20 in netbox, and forget about all the rest,,,

I'm not sure I understand here. So while the device uses the following names:

GigabitEthernet0/0/0/20
TenGigE0/0/0/20

You would just use Eth0/0/0/20 for both configurations? If that's the case, that would not work for us. We rely on netbox representing the real world to allow automation.

Total disclosure, I'm not really a networking guy, so the request is as explained by our users at my place of work. There might very well be a better/more correct way of doing it. I still think the feature makes sense though, at least as much as mgmt_only being avalible on interface templates. I'll ask for feedback form our users.

@kkthxbye-code commented on GitHub (Jan 9, 2023): @PieterL75 - Our users prefer to have both interfaces and disable the one not being used. It also helps with custom scripts where the user has to choose an interface, as it allows both configurations to be shown and we can do the enabling of the chosen interface. > The slot/mod/port/forgotwhattheyare should be the identifiers... > I even tend to just put Eth0/0/0/20 in netbox, and forget about all the rest,,, I'm not sure I understand here. So while the device uses the following names: > GigabitEthernet0/0/0/20 > TenGigE0/0/0/20 You would just use Eth0/0/0/20 for both configurations? If that's the case, that would not work for us. We rely on netbox representing the real world to allow automation. Total disclosure, I'm not really a networking guy, so the request is as explained by our users at my place of work. There might very well be a better/more correct way of doing it. I still think the feature makes sense though, at least as much as mgmt_only being avalible on interface templates. I'll ask for feedback form our users.
adam commented 2025-12-29 20:23:56 +01:00
Author
Owner
Copy Link

@sleepinggenius2 commented on GitHub (Jan 10, 2023):

We don't create duplicate interfaces like in @kkthxbye-code's example, but still face the same problem. In our use case, devices are often deployed with the majority of their interfaces disabled. When we just had DeviceTypes, this was annoying, but manageable, to go into a device after it was instantiated, do a select all, deselect the handful of interfaces that were being used for uplinks, then do a bulk edit to set them all as disabled. The addition of modules make this significantly more painful, as we have a number of high-density cards that have maybe 48 interfaces on them and so now when you slot in that module in NetBox, you have to find just those interfaces that it added in order to select and disable them. This had led to a number of problems, and ultimately workarounds, to be able to support automated provisioning without leaving a bunch of interfaces enabled that generate alarms in our monitoring application for being Up/Down, when the engineers inevitably forget to manually disable the interfaces they aren't using.

@sleepinggenius2 commented on GitHub (Jan 10, 2023): We don't create duplicate interfaces like in @kkthxbye-code's example, but still face the same problem. In our use case, devices are often deployed with the majority of their interfaces disabled. When we just had DeviceTypes, this was annoying, but manageable, to go into a device after it was instantiated, do a select all, deselect the handful of interfaces that were being used for uplinks, then do a bulk edit to set them all as disabled. The addition of modules make this significantly more painful, as we have a number of high-density cards that have maybe 48 interfaces on them and so now when you slot in that module in NetBox, you have to find just those interfaces that it added in order to select and disable them. This had led to a number of problems, and ultimately workarounds, to be able to support automated provisioning without leaving a bunch of interfaces enabled that generate alarms in our monitoring application for being Up/Down, when the engineers inevitably forget to manually disable the interfaces they aren't using.
adam commented 2025-12-29 20:23:56 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 10, 2023):

This is largely going to be dependent on caveats across different platforms, but I want to clarify that the enabled field should only be used to document an interface's administrative state, and not as a hint for any other function. With regard to interfaces that get renamed based on their configured speed (as in the example above), only one or the other name should be present on the device in NetBox. The exception would be if the device normally represents both variations in its native configuration; again, this is all platform-dependent.

That said, I'm in favor of adding an enabled field to the InterfaceTemplate model for the purpose of disabling interfaces upon instantiation on a new device or module where needed.

@jeremystretch commented on GitHub (Jan 10, 2023): This is largely going to be dependent on caveats across different platforms, but I want to clarify that the `enabled` field should only be used to document an interface's _administrative_ state, and not as a hint for any other function. With regard to interfaces that get renamed based on their configured speed (as in the example above), only one or the other name should be present on the device in NetBox. The exception would be if the device normally represents both variations in its native configuration; again, this is all platform-dependent. That said, I'm in favor of adding an `enabled` field to the InterfaceTemplate model for the purpose of disabling interfaces upon instantiation on a new device or module where needed.
adam commented 2025-12-29 20:23:56 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Jan 10, 2023):

This feels like a customfield solution. Add a Field that holds the info you need, so that it works the way you want..

@PieterL75 commented on GitHub (Jan 10, 2023): This feels like a customfield solution. Add a Field that holds the info you need, so that it works the way you want..
adam commented 2025-12-29 20:23:57 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Jan 10, 2023):

@PieterL75 - Custom fields are not replicated.

@kkthxbye-code commented on GitHub (Jan 10, 2023): @PieterL75 - Custom fields are not replicated.
adam commented 2025-12-29 20:23:57 +01:00
Author
Owner
Copy Link

@PieterL75 commented on GitHub (Jan 10, 2023):

I must have missed the part that he requested this to be added to the template.. you're right, CF will not cut it then

@PieterL75 commented on GitHub (Jan 10, 2023): I must have missed the part that he requested this to be added to the template.. you're right, CF will not cut it then
adam commented 2025-12-29 20:23:57 +01:00
Author
Owner
Copy Link

@kkthxbye-code commented on GitHub (Jan 10, 2023):

I realize this is still under review, but I wanted to just create the PR as the code was done as a quick PoC already. If the FR is ultimately rejected it can easily be closed.

@kkthxbye-code commented on GitHub (Jan 10, 2023): I realize this is still under review, but I wanted to just create the PR as the code was done as a quick PoC already. If the FR is ultimately rejected it can easily be closed.
adam commented 2025-12-29 20:23:57 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 12, 2023):

This will need to wait for v3.5 as it introduces a new database field. But I'm fine with tagging it as a milestone.

@jeremystretch commented on GitHub (Jan 12, 2023): This will need to wait for v3.5 as it introduces a new database field. But I'm fine with tagging it as a milestone.
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 status: accepted 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#7480
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?