Add decommissioning as device status

[clercrobin]

Environment

• Python version: 3.6.7
• NetBox version: 2.5.10

Proposed Functionality

To extend the issue #154, we want to add a status decommissioning to the already existing status list:

• offline
• active
• planned
• staged
• failed
• inventory

Use Case

We are currently using Netbox as our asset management system, in addition to its DCIM functionality and are quite happy with this. A valuable output from Netbox would be a forecasting vision enabled by a status like planned. However it is not sufficient to complete this functionality and thus to indicate that a machine will be soon offline we want to add the status decommissioning.

It would enable the 2 following views:

• Current status: Active + decommissioning
• Forecast: Active + planned

Database Changes

The device statuses lines (314 - 328) of the file netbox\dcim\constants.py would change to:

STATUS_OFFLINE = 0
STATUS_ACTIVE = 1
STATUS_PLANNED = 2
STATUS_STAGED = 3
STATUS_FAILED = 4
STATUS_INVENTORY = 5
STATUS_DECOMMISSIONING = 6
DEVICE_STATUS_CHOICES = [
    [DEVICE_STATUS_ACTIVE, 'Active'],
    [DEVICE_STATUS_OFFLINE, 'Offline'],
    [DEVICE_STATUS_PLANNED, 'Planned'],
    [DEVICE_STATUS_STAGED, 'Staged'],
    [DEVICE_STATUS_FAILED, 'Failed'],
    [DEVICE_STATUS_INVENTORY, 'Inventory'],
    [DEVICE_STATUS_DECOMMISSIONING, 'Decommissioning'],
]

External Dependencies

No external dependancy

[kasimon]

Even when not (mis-)using netbox as an asset management tool, having a decomissioning (or to-be-decomissioned) status would be valuable, as it would make clear that the device is not ment to be repaired or taken back online, but is still taking up space in the datacenter until it has been removed from the rack and from netbox. So +1 from me.

[paravoid]

+1 this, but (despite how much I like opinionated software) I would actually argue in favor of making all statuses site-configurable, e.g. via the admin panel, rather than trying to have a one-setting-fits-all.

Wikimedia has mapped Netbox's statuses to our own stages but I think we'd be better served if we were able to rename them to fit our own terminology, as well as add or remove stages as needed.

If that makes sense we can take a stab at implementing that, although I suspect it may be relatively trivial for someone that already knows the codebase :)

[mmahacek]

@clercrobin check the last two lines of your sample status choices. I like the idea of a status to indicate a planned removal, but do prefer to have the reasons curated and not customizable per server.