Expand device status beyond active/offline #116

New Issue

adam · 2025-12-29T15:33:39+01:00

adam commented

2025-12-29 15:33:39 +01:00

Originally created by @peelman on GitHub (Jul 1, 2016).

Not so much an issue but a topic of discussion, as I am not sure where even I stand on this; right now Device->Status is defined as Bool, with two states, Active or Offline.

Aside from the semantic differences (Use Online/Offline, Active/Inactive, or some other matching pair), should there be more than two states a device can be in?

[STATUS_ACTIVE, 'Active'],
[STATUS_INACTIVE, 'Inactive'],
[STATUS_DISABLED, 'Disabled'],
[STATUS_STORAGE, 'Storage'],
[STATUS_MISSING, 'Missing'],
[STATUS_LOANED, 'On Loan'],
[STATUS_DESTROYED, 'Destroyed'],
[STATUS_SOLD, 'Sold'],
[STATUS_Stolen, 'Stolen'],

I'll admit, I have a hard time not treating the Devices section as an Asset Management system (right now its tailored to Rack mounted gear, but there are lots of things in data centers to keep tabs and accountability on that don't go in racks). Each of those states represents a state of equipment we were tracking at one point or another.

Or should this be a lookup table that is configurable by the end user as needed?

Originally created by @peelman on GitHub (Jul 1, 2016). Not so much an issue but a topic of discussion, as I am not sure where even I stand on this; right now Device->Status is defined as Bool, with two states, Active or Offline. Aside from the semantic differences (Use Online/Offline, Active/Inactive, or some other matching pair), should there be more than two states a device can be in? ``` [STATUS_ACTIVE, 'Active'], [STATUS_INACTIVE, 'Inactive'], [STATUS_DISABLED, 'Disabled'], [STATUS_STORAGE, 'Storage'], [STATUS_MISSING, 'Missing'], [STATUS_LOANED, 'On Loan'], [STATUS_DESTROYED, 'Destroyed'], [STATUS_SOLD, 'Sold'], [STATUS_Stolen, 'Stolen'], ``` I'll admit, I have a hard time not treating the Devices section as an Asset Management system (right now its tailored to Rack mounted gear, but there are lots of things in data centers to keep tabs and accountability on that don't go in racks). Each of those states represents a state of equipment we were tracking at one point or another. Or should this be a lookup table that is configurable by the end user as needed?

adam added the type: feature label 2025-12-29 15:33:39 +01:00

adam closed this issue

2025-12-29 15:33:39 +01:00

adam commented

2025-12-29 15:33:40 +01:00

@jeremystretch commented on GitHub (Jul 1, 2016):

To lend a bit of context, the status field was originally just used to indicate whether NetBox should attempt to pull inventory/LLDP from a device, etc. But this is a really interesting idea and I'd love to hear what others think.

@jeremystretch commented on GitHub (Jul 1, 2016): To lend a bit of context, the `status` field was originally just used to indicate whether NetBox should attempt to pull inventory/LLDP from a device, etc. But this is a really interesting idea and I'd love to hear what others think.

adam commented

2025-12-29 15:33:40 +01:00

@bellwood commented on GitHub (Jul 1, 2016):

Well if its active, then pull LLDP otherwise no but having alternative statuses is a great idea.

A status for repair and/or RMA would be nice too so you can track those states

Are status changes going to be logged in the device history? That would be great so you could track how long a device was out for RMA or been active, etc.

@bellwood commented on GitHub (Jul 1, 2016): Well if its active, then pull LLDP otherwise no but having alternative statuses is a great idea. A status for repair and/or RMA would be nice too so you can track those states Are status changes going to be logged in the device history? That would be great so you could track how long a device was out for RMA or been active, etc.

adam commented

2025-12-29 15:33:41 +01:00

@jeremystretch commented on GitHub (Jul 20, 2016):

I think if we extend the concept of status beyond merely "online" or "offline," there's going to be too much variation among users to define a concise but inclusive list. (I'd also feel uncomfortable showing our leadership a tool that has "stolen" as a possible device status. 😄 )

I'm going to close this out in favor of #129 (custom fields), which should allow for exactly this functionality but as a completely customizable list.

@jeremystretch commented on GitHub (Jul 20, 2016): I think if we extend the concept of `status` beyond merely "online" or "offline," there's going to be too much variation among users to define a concise but inclusive list. (I'd also feel uncomfortable showing our leadership a tool that has "stolen" as a possible device status. :smile: ) I'm going to close this out in favor of #129 (custom fields), which should allow for exactly this functionality but as a completely customizable list.

adam commented

2025-12-29 15:33:41 +01:00

@jeremystretch commented on GitHub (Mar 2, 2017):

Reopening this feature request. I think there's merit for extending the status field, or at least adding a separate field to track this sort of state.

@jeremystretch commented on GitHub (Mar 2, 2017): Reopening this feature request. I think there's merit for extending the status field, or at least adding a separate field to track this sort of state.

adam commented

2025-12-29 15:33:41 +01:00

@puck commented on GitHub (Mar 2, 2017):

While I really like the idea of having different status information, this does start to blend towards the asset management side of things. Not that i think this is a bad thing personally!

The benefit from my point of view is that when a device is no longer racked, we don't lose the history. Currently my colleagues will tend to delete a device as soon as it is de-racked.

@puck commented on GitHub (Mar 2, 2017): While I really like the idea of having different status information, this does start to blend towards the asset management side of things. Not that i think this is a bad thing personally! The benefit from my point of view is that when a device is no longer racked, we don't lose the history. Currently my colleagues will tend to delete a device as soon as it is de-racked.

adam commented

2025-12-29 15:33:42 +01:00

@jeremystretch commented on GitHub (Mar 2, 2017):

While I don't want to get into asset management territory, I do think it would be reasonable to include subsets of the "offline" status. For example, a state that would indicate hardware failure and another that would indicate that the device has been tagged for deinstallation.

@jeremystretch commented on GitHub (Mar 2, 2017): While I don't want to get into asset management territory, I do think it would be reasonable to include subsets of the "offline" status. For example, a state that would indicate hardware failure and another that would indicate that the device has been tagged for deinstallation.

adam commented

2025-12-29 15:33:43 +01:00

@puck commented on GitHub (Mar 2, 2017):

Yes, both of those examples would be very handy.

@puck commented on GitHub (Mar 2, 2017): Yes, both of those examples would be very handy.

adam commented

2025-12-29 15:33:43 +01:00

@jeremystretch commented on GitHub (May 8, 2017):

Expanding the boolean field to include the following device statuses:

STATUS_OFFLINE = 0
STATUS_ACTIVE = 1
STATUS_PLANNED = 2
STATUS_STAGED = 3
STATUS_FAILED = 4
STATUS_INVENTORY = 5

@jeremystretch commented on GitHub (May 8, 2017): Expanding the boolean field to include the following device statuses: ``` STATUS_OFFLINE = 0 STATUS_ACTIVE = 1 STATUS_PLANNED = 2 STATUS_STAGED = 3 STATUS_FAILED = 4 STATUS_INVENTORY = 5 ```

adam referenced this issue

2025-12-29 16:23:49 +01:00

VLAN “Service Identifier” field (VXLAN or ISID) #607

adam referenced this issue

2025-12-29 16:28:39 +01:00

802.1ad (AKA: QinQ, Service Tag) #1083

adam referenced this issue

2025-12-29 16:32:04 +01:00

VXLAN ID (called VXLAN Network Identifier or VNI) #1411

Sign in to join this conversation.