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

Expand device status with one additional status label #4140

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

Originally created by @CodyChell on GitHub (Sep 25, 2020).

Environment

  • Python version: 3.6.9
  • NetBox version: 2.9.4

WorkFlow

Specifically, just expanding upon status labels inside of Netbox devices. Status labels since the expansion of them since this feature request: https://github.com/netbox-community/netbox/issues/154

This feature was a great value-added addition to device status information, but I believe just reduce potential confusion between people who may not constantly be managing the tool and are specifically just to get status information about devices in the environment or previous devices that were in the environment.

The request is to add an additional status label OR add the functionality to create your own custom status labels. It would allow for a lot more flexibility to describe the current status of devices. Whichever is easiest. Likely the former.

If you were just to add the 1 additional status label and not move forward with custom fields
The one additional status label would be to add a "DECOMMISSIONED" status label.

I believe that this addition may clear up some confusion that I've been having with marking devices inside my Netbox environment. It seems to me that the INVENTORY label may be an inadequate status label for certain cases that pertain a device refresh process, because that device is likely has been recycled/cannibalized. I have also used the OFFLINE status for the purpose of a completed decommission. This could also be misleading. Believing that the server is likely still in the environment but it is just offline. This status label would entirely be for the purpose of record keeping. Being able to keep dates/times when devices were marked for DECOMMISSIONING status and then ultimately completed the process, and has been marked as a completed decommission.

If you were to have custom fields you may have an increase in flexibility for marking assets for very specific needs. But unlikely to be needed, in my opinion. Just a thought.

Proposed Functionality

Just the addition of having 1 extra option under device statuses.

Going over current statuses and the proposed addition of one more descriptive status. Please tell me if I am not understanding these properly/not using the status labels in our Netbox environment properly.

OFFLINE - Device is still in rack, device is offline, not pingable/no power.
ACTIVE - Device is on, running, and accessible.
PLANNED - Planned device addition to the network.
STAGED - Device is in place, ready to go into active state.
FAILED - Device hardware failed, removed from rack.
INVENTORY - Assuming from what I've read from the documentation this is primarily for pieces of devices. Example: HDD's/Processors for servers. But I have marked some servers as INVENTORY as the place holder for my proposed status label addition.
DECOMMISSIONING - In the process of Decommissioning the device/marked for decommission due to refresh or other reason. NOT because the device failed.

++ DECOMMISSIONED - Meaning the device has completed the DECOMMISSIONING state and all process/work loads have been removed from prod on this device and the device is removed from rack, or in the process of removal.

As I believe I have already explained above, a use case for this would still be for a server refresh and for documentation purposes.

If at all possible adding the option to have custom status labels under the custom fields option. This custom field would be separate from where custom fields show up on a device. Your custom options would show up in the selection choices for the status of the device. Like I said I believe this addition would be much bigger task than just adding the one label. It is not a requirement right now or really in the future, I believe. It would just really be a cherry on top.

Use Case

Use case would be able to mark devices that are no longer in the environment, no longer active, and not an option to be offline because I believe offline and decommissioned to be two separate labels/statuses. It would draw clearer lines between the status of individual devices.

Database Changes

None, if any? Not really sure if much would have to change.

External Dependencies

No external dependencies should be needed, I believe.

Originally created by @CodyChell on GitHub (Sep 25, 2020). ### Environment * Python version: 3.6.9 * NetBox version: 2.9.4 <!-- --> ### WorkFlow Specifically, just expanding upon status labels inside of Netbox devices. Status labels since the expansion of them since this feature request: https://github.com/netbox-community/netbox/issues/154 This feature was a great value-added addition to device status information, but I believe just reduce potential confusion between people who may not constantly be managing the tool and are specifically just to get status information about devices in the environment or previous devices that were in the environment. The request is to add an additional status label OR add the functionality to create your own custom status labels. It would allow for a lot more flexibility to describe the current status of devices. Whichever is easiest. Likely the former. If you were just to add the 1 additional status label and not move forward with custom fields The one additional status label would be to add a "DECOMMISSIONED" status label. I believe that this addition may clear up some confusion that I've been having with marking devices inside my Netbox environment. It seems to me that the INVENTORY label may be an inadequate status label for certain cases that pertain a device refresh process, because that device is likely has been recycled/cannibalized. I have also used the OFFLINE status for the purpose of a completed decommission. This could also be misleading. Believing that the server is likely still in the environment but it is just offline. This status label would entirely be for the purpose of record keeping. Being able to keep dates/times when devices were marked for DECOMMISSIONING status and then ultimately completed the process, and has been marked as a completed decommission. If you were to have custom fields you may have an increase in flexibility for marking assets for very specific needs. But unlikely to be needed, in my opinion. Just a thought. <!-- --> ### Proposed Functionality Just the addition of having 1 extra option under device statuses. Going over current statuses and the proposed addition of one more descriptive status. Please tell me if I am not understanding these properly/not using the status labels in our Netbox environment properly. OFFLINE - Device is still in rack, device is offline, not pingable/no power. ACTIVE - Device is on, running, and accessible. PLANNED - Planned device addition to the network. STAGED - Device is in place, ready to go into active state. FAILED - Device hardware failed, removed from rack. INVENTORY - Assuming from what I've read from the documentation this is primarily for pieces of devices. Example: HDD's/Processors for servers. But I have marked some servers as INVENTORY as the place holder for my proposed status label addition. DECOMMISSIONING - In the process of Decommissioning the device/marked for decommission due to refresh or other reason. NOT because the device failed. ++ DECOMMISSIONED - Meaning the device has completed the DECOMMISSIONING state and all process/work loads have been removed from prod on this device and the device is removed from rack, or in the process of removal. As I believe I have already explained above, a use case for this would still be for a server refresh and for documentation purposes. If at all possible adding the option to have custom status labels under the custom fields option. This custom field would be separate from where custom fields show up on a device. Your custom options would show up in the selection choices for the status of the device. Like I said I believe this addition would be much bigger task than just adding the one label. It is not a requirement right now or really in the future, I believe. It would just really be a cherry on top. <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. Going over current statuses and the proposed addition of one more descriptive status. Please tell me if I am not understanding these properly/not using the status labels in our Netbox environment properly. OFFLINE - Device is still in rack, device is offline, not pingable/no power. ACTIVE - Device is on, running, and accessible. PLANNED - Planned device addition to the network. STAGED - Device is in place, ready to go into active state. FAILED - Device hardware failed, removed from rack. INVENTORY - Assuming from what I've read from the documentation this is primarily for pieces of devices. Example: HDD's/Processors for servers. But I have marked some servers as INVENTORY as the place holder for my proposed status label addition. DECOMMISSIONING - In the process of Decommissioning the device/marked for decommission due to refresh or other reason. NOT because the device failed. ++ DECOMMISSIONED - Meaning the device has completed the DECOMMISSIONING state and all processes/work loads have been removed from prod on this device and the device is removed from rack, or in the process of removal. As I believe I have already explained in the WorkFlow section, a use case for this would still be for a server refresh and for documentation purposes. I know this moves Netbox a little closer to being an "Asset Management" system. But I believe that having this status label wouldn't skew the lines that much more between being a "Source of Truth" and "Asset Management". It kinda plays to both. Being able to be more descriptive about what you wish your environment to look like what what the status of it actually is. ---> ### Use Case Use case would be able to mark devices that are no longer in the environment, no longer active, and not an option to be offline because I believe offline and decommissioned to be two separate labels/statuses. It would draw clearer lines between the status of individual devices. <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes None, if any? Not really sure if much would have to change. <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) Shouldn't be any additional dependencies if just adding the one additional status label. --> ### External Dependencies No external dependencies should be needed, I believe.
adam added the pending closure label 2025-12-29 18:33:23 +01:00
adam closed this issue 2025-12-29 18:33:24 +01:00
adam commented 2025-12-29 18:33:24 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 25, 2020):

I don't see a functional difference between "decommissioned" and staged." Honestly if you need such fine-grained control over status, you're probably better off using tags to denote whether specific conditions have been met.

@jeremystretch commented on GitHub (Sep 25, 2020): I don't see a functional difference between "decommissioned" and staged." Honestly if you need such fine-grained control over status, you're probably better off using tags to denote whether specific conditions have been met.
adam commented 2025-12-29 18:33:24 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Sep 26, 2020):

INVENTORY - Assuming from what I've read from the documentation this is primarily for pieces of devices. Example: HDD's/Processors for servers. But I have marked some servers as INVENTORY as the place holder for my proposed status label addition.

No, I think you are confusing inventory items here. They are components added to devices. You would not track them as individual devices in NetBox, and therefore they do not have a status attribute. With that understanding, the "Inventory" status actually maps closely to your described use case.

Additionally, NetBox is not intended to be a generic asset management system. That is not one of our core competencies, and thus we have no real interest in tracking gear that is not serving a purpose on the network.

@lampwins commented on GitHub (Sep 26, 2020): > INVENTORY - Assuming from what I've read from the documentation this is primarily for pieces of devices. Example: HDD's/Processors for servers. But I have marked some servers as INVENTORY as the place holder for my proposed status label addition. No, I think you are confusing inventory items here. They are components added to devices. You would not track them as individual devices in NetBox, and therefore they do not have a status attribute. With that understanding, the "Inventory" status actually maps closely to your described use case. Additionally, NetBox is not intended to be a generic asset management system. That is not one of our core competencies, and thus we have no real interest in tracking gear that is not serving a purpose on the network.
adam commented 2025-12-29 18:33:24 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Nov 10, 2020):

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. Please see our contributing guide.

@stale[bot] commented on GitHub (Nov 10, 2020): 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:33:24 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Nov 26, 2020):

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.

@stale[bot] commented on GitHub (Nov 26, 2020): 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.
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 pending closure
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#4140
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?