Add DCIM/Interface status field for consistency #8895

New Issue

adam · 2025-12-29T20:42:35+01:00

adam commented

2025-12-29 20:42:35 +01:00

Originally created by @proy-rbbn on GitHub (Nov 29, 2023).

NetBox version

v3.6.5

Feature type

Data model extension

Proposed functionality

Requesting that the device interface object have a status dropdown field added which contains options:

Active
Planned
Failed
To be removed

Use case

Device Interface objects are some of the few objects in netbox that do not have a status field to allow for easy identification of newly engineered interfaces. This status field exists for Device objects, Connections, IP addresses. We use netbox as our single source of truth. We engineer/pre-build our switch configurations in netbox. We use ansible playbooks to pull from netbox device, interface, ip address as well as other data and then push that configuration into our switches. This status inconsistency in the device interface data model (i.e. no status field) makes it very difficult to use ansible to parse the data in netbox for newly added or to be removed interfaces.

Database changes

Object: dcim/interfaces
Field name: status
Type: array[string]
Values:
active - Active
planned - Planned
failed - Failed
to-be-removed - To be removed

External dependencies

None.

Originally created by @proy-rbbn on GitHub (Nov 29, 2023). ### NetBox version v3.6.5 ### Feature type Data model extension ### Proposed functionality Requesting that the device interface object have a status dropdown field added which contains options: - Active - Planned - Failed - To be removed ### Use case Device Interface objects are some of the few objects in netbox that do not have a status field to allow for easy identification of newly engineered interfaces. This status field exists for Device objects, Connections, IP addresses. We use netbox as our single source of truth. We engineer/pre-build our switch configurations in netbox. We use ansible playbooks to pull from netbox device, interface, ip address as well as other data and then push that configuration into our switches. This status inconsistency in the device interface data model (i.e. no status field) makes it very difficult to use ansible to parse the data in netbox for newly added or to be removed interfaces. ### Database changes Object: dcim/interfaces Field name: status Type: array[string] Values: active - Active planned - Planned failed - Failed to-be-removed - To be removed ### External dependencies None.

adam added the type: feature pending closure complexity: low labels 2025-12-29 20:42:35 +01:00

adam closed this issue

2025-12-29 20:42:35 +01:00

adam commented

2025-12-29 20:42:36 +01:00

@ITJamie commented on GitHub (Nov 29, 2023):

I would argue for staged to be add aswell. It would be useful for tracking ports which have config on for testing purposes / poc's

inventory items are also missing the status field and it would be useful there too

@ITJamie commented on GitHub (Nov 29, 2023): I would argue for staged to be add aswell. It would be useful for tracking ports which have config on for testing purposes / poc's inventory items are also missing the status field and it would be useful there too

adam commented

2025-12-29 20:42:36 +01:00

@jeremystretch commented on GitHub (Nov 29, 2023):

This status field exists for Device objects, Connections, IP addresses.

These objects can all be created and removed arbitrarily. The same is not necessarily true for interfaces, particularly physical interfaces.

You haven't cited a specific use case. Can you give an example of a situation where you need to add an interface to a device, but designate it as having not been created?

Additionally, why have you proposed this only for interfaces and not other device components? And what about virtual machine interfaces?

@jeremystretch commented on GitHub (Nov 29, 2023): > This status field exists for Device objects, Connections, IP addresses. These objects can all be created and removed arbitrarily. The same is not necessarily true for interfaces, particularly physical interfaces. You haven't cited a specific use case. Can you give an example of a situation where you need to add an interface to a device, but designate it as having not been created? Additionally, why have you proposed this only for interfaces and not other device components? And what about virtual machine interfaces?

adam commented

2025-12-29 20:42:36 +01:00

@sleepinggenius2 commented on GitHub (Nov 29, 2023):

One thing that I came across recently when I added a module in a Planned status to a device for the first time, was that it populated all of its interfaces within the device, but there was no easy way to tell that those interfaces do not actually exist on the device at this time. That would also hold true for other device components associated with that module. Some way to indicate that those components are also Planned would be helpful in that situation. That's really the main scenario I can think of for having a physical port in a Planned status, though since NetBox doesn't generally model pluggables as modules, I can also see a scenario where one might want to mark an SFP-based port with a different status to, for example, indicate that it's been configured, but still needs an optic populated before it can go into service. Ultimately, support for nested modules might obviate the use case for that though.

For virtual interfaces, there are a number of cases where you might want to "reserve" that interface name. For example, if you're planning a cut-over where you're moving an L3 interface from a port to a sub-interface, from a sub-interface to a BVI/SVI, a single port to a LAG, etc. Something service-affecting like that typically needs to be done in a maintenance window, so you wouldn't want it to become immediately active, especially if you are leveraging network automation. To be honest though, that's somewhere that I would really like to see staged changes be able to be used more effectively.

Inventory items I would lump into the same category as modules, so those could really do with a status field as well, but that might deserve a separate feature request.

@sleepinggenius2 commented on GitHub (Nov 29, 2023): One thing that I came across recently when I added a module in a Planned status to a device for the first time, was that it populated all of its interfaces within the device, but there was no easy way to tell that those interfaces do not actually exist on the device at this time. That would also hold true for other device components associated with that module. Some way to indicate that those components are also Planned would be helpful in that situation. That's really the main scenario I can think of for having a physical port in a Planned status, though since NetBox doesn't generally model pluggables as modules, I can also see a scenario where one might want to mark an SFP-based port with a different status to, for example, indicate that it's been configured, but still needs an optic populated before it can go into service. Ultimately, support for nested modules might obviate the use case for that though. For virtual interfaces, there are a number of cases where you might want to "reserve" that interface name. For example, if you're planning a cut-over where you're moving an L3 interface from a port to a sub-interface, from a sub-interface to a BVI/SVI, a single port to a LAG, etc. Something service-affecting like that typically needs to be done in a maintenance window, so you wouldn't want it to become immediately active, especially if you are leveraging network automation. To be honest though, that's somewhere that I would really like to see staged changes be able to be used more effectively. Inventory items I would lump into the same category as modules, so those could really do with a status field as well, but that might deserve a separate feature request.

adam commented

2025-12-29 20:42:36 +01:00

@jdavidson2021 commented on GitHub (Dec 14, 2023):

This status field exists for Device objects, Connections, IP addresses.

These objects can all be created and removed arbitrarily. The same is not necessarily true for interfaces, particularly physical interfaces.

You haven't cited a specific use case. Can you give an example of a situation where you need to add an interface to a device, but designate it as having not been created?

Additionally, why have you proposed this only for interfaces and not other device components? And what about virtual machine interfaces?

We use NetBox as an upfront planning/engineering tool. Just because a physical interface exists on a device, that doesn't mean that it is configured and ready for use. We may initially engineer, configure, and install a device and then at a later date add additional configuration to interfaces (descriptions, VLANS, etc.). One person may engineer/document the new interface configuration in NetBox and a different person (or automation tool) may use that configuration at a later date to actually configure and turn-up the interface. This feature would give us the ability to easily identify interface configuration that still needs to be added to a device. It would also apply to virtual machines and any other device components that could be added at a later date from the initial installation.

@jdavidson2021 commented on GitHub (Dec 14, 2023): > > This status field exists for Device objects, Connections, IP addresses. > > These objects can all be created and removed arbitrarily. The same is not necessarily true for interfaces, particularly physical interfaces. > > You haven't cited a specific use case. Can you give an example of a situation where you need to add an interface to a device, but designate it as having not been created? > > Additionally, why have you proposed this only for interfaces and not other device components? And what about virtual machine interfaces? We use NetBox as an upfront planning/engineering tool. Just because a physical interface exists on a device, that doesn't mean that it is configured and ready for use. We may initially engineer, configure, and install a device and then at a later date add additional configuration to interfaces (descriptions, VLANS, etc.). One person may engineer/document the new interface configuration in NetBox and a different person (or automation tool) may use that configuration at a later date to actually configure and turn-up the interface. This feature would give us the ability to easily identify interface configuration that still needs to be added to a device. It would also apply to virtual machines and any other device components that could be added at a later date from the initial installation.

adam commented

2025-12-29 20:42:37 +01:00

@jdavidson2021 commented on GitHub (Dec 14, 2023):

I would argue for staged to be add aswell. It would be useful for tracking ports which have config on for testing purposes / poc's

inventory items are also missing the status field and it would be useful there too

Staged and Planned are very similar.

@jdavidson2021 commented on GitHub (Dec 14, 2023): > I would argue for staged to be add aswell. It would be useful for tracking ports which have config on for testing purposes / poc's > > inventory items are also missing the status field and it would be useful there too Staged and Planned are very similar.

adam commented

2025-12-29 20:42:37 +01:00

@github-actions[bot] commented on GitHub (May 15, 2024):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (May 15, 2024): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented

2025-12-29 20:42:37 +01:00

@github-actions[bot] commented on GitHub (Jun 22, 2024):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (Jun 22, 2024): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

adam referenced this issue

2025-12-29 20:42:48 +01:00

Add network model #8913

Sign in to join this conversation.

Branches Tags

main

21102-fix-graphiql-explorer

update-changelog-comments-docs

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#8895