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

Status Decommissioning missing for virtual machines #3275

New Issue
Closed
opened 2025-12-29 18:27:20 +01:00 by adam · 14 comments
adam commented 2025-12-29 18:27:20 +01:00
Owner
Copy Link

Originally created by @netsandbox on GitHub (Feb 5, 2020).

Originally assigned to: @kobayashi on GitHub.

Environment

  • Python version: 3.6.9
  • NetBox version: 2.7.4

Proposed Functionality

Currently a virtual machine can only have as status:

  • Active
  • Offline
  • Staged

I'm missing here at least Decommissioning as status.

Use Case

I would distinguish between Offline and Decommissioning in this way:

Offline is a VM that is temporary powered off and will be later powered on again.
Decommissioning is a VM that is powered off and will be later deleted.

Our decommissioning process is actually to power off a VM and then wait a reasonable time if still someone came up who needs this VM.
Being able to set Decommissioning as status would help to track VM's planned for decommissioning.

Maybe it also makes sense to use for virtual machines the same status as for devices.
If you think of devices as hardware servers, the same processes are often used for hardware servers and VM's. Having the same status choices for both of them would help here.

Database Changes

None

External Dependencies

None

Originally created by @netsandbox on GitHub (Feb 5, 2020). Originally assigned to: @kobayashi on GitHub. ### Environment * Python version: 3.6.9 * NetBox version: 2.7.4 ### Proposed Functionality Currently a virtual machine can only have as status: * Active * Offline * Staged I'm missing here at least Decommissioning as status. ### Use Case I would distinguish between Offline and Decommissioning in this way: **Offline** is a VM that is temporary powered off and will be later powered on again. **Decommissioning** is a VM that is powered off and will be later deleted. Our decommissioning process is actually to power off a VM and then wait a reasonable time if still someone came up who needs this VM. Being able to set Decommissioning as status would help to track VM's planned for decommissioning. Maybe it also makes sense to use for virtual machines the same status as for devices. If you think of devices as hardware servers, the same processes are often used for hardware servers and VM's. Having the same status choices for both of them would help here. ### Database Changes None ### External Dependencies None
adam added the status: acceptedtype: feature labels 2025-12-29 18:27:20 +01:00
adam closed this issue 2025-12-29 18:27:20 +01:00
adam commented 2025-12-29 18:27:20 +01:00
Author
Owner
Copy Link

@kobayashi commented on GitHub (Feb 6, 2020):

This is reasonable to me. when it accepted, let me set Decommissioning to virtual machine.

This change will be like this. LEGACY_MAP might not be necessary?

class VirtualMachineStatusChoices(ChoiceSet):

    STATUS_ACTIVE = 'active'
    STATUS_OFFLINE = 'offline'
    STATUS_STAGED = 'staged'
    STATUS_DECOMMISSIONING = 'decommissioning'

    CHOICES = (
        (STATUS_ACTIVE, 'Active'),
        (STATUS_OFFLINE, 'Offline'),
        (STATUS_STAGED, 'Staged'),
        (STATUS_DECOMMISSIONING, 'Decommissioning'),
    )

    LEGACY_MAP = {
        STATUS_OFFLINE: 0,
        STATUS_ACTIVE: 1,
        STATUS_STAGED: 3,
        STATUS_DECOMMISSIONING: 4,
    }
@kobayashi commented on GitHub (Feb 6, 2020): This is reasonable to me. when it accepted, let me set Decommissioning to virtual machine. This change will be like this. LEGACY_MAP might not be necessary? ``` class VirtualMachineStatusChoices(ChoiceSet): STATUS_ACTIVE = 'active' STATUS_OFFLINE = 'offline' STATUS_STAGED = 'staged' STATUS_DECOMMISSIONING = 'decommissioning' CHOICES = ( (STATUS_ACTIVE, 'Active'), (STATUS_OFFLINE, 'Offline'), (STATUS_STAGED, 'Staged'), (STATUS_DECOMMISSIONING, 'Decommissioning'), ) LEGACY_MAP = { STATUS_OFFLINE: 0, STATUS_ACTIVE: 1, STATUS_STAGED: 3, STATUS_DECOMMISSIONING: 4, } ```
adam commented 2025-12-29 18:27:21 +01:00
Author
Owner
Copy Link

@kobayashi commented on GitHub (Feb 6, 2020):

Just opened PR #4102 before accepted.
That could be merged if this issue will be accepted.

@kobayashi commented on GitHub (Feb 6, 2020): Just opened PR #4102 before accepted. That could be merged if this issue will be accepted.
adam commented 2025-12-29 18:27:21 +01:00
Author
Owner
Copy Link

@nathbooth commented on GitHub (Feb 11, 2020):

Can we expand this further and add all the missing status's to give vms parity with devices. so add;

  • Planned
  • Staged
  • Failed
  • Inventory
@nathbooth commented on GitHub (Feb 11, 2020): Can we expand this further and add all the missing status's to give vms parity with devices. so add; - Planned - Staged - Failed - Inventory
adam commented 2025-12-29 18:27:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 12, 2020):

I don't see a valid use case for staged or inventory. A staged device is one that has been physically installed but not yet provisioned: This concept doesn't apply to virtual machines. Same with inventory.

Planned and failed make sense, I think.

@jeremystretch commented on GitHub (Feb 12, 2020): I don't see a valid use case for staged or inventory. A staged device is one that has been physically installed but not yet provisioned: This concept doesn't apply to virtual machines. Same with inventory. Planned and failed make sense, I think.
adam commented 2025-12-29 18:27:21 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Feb 12, 2020):

I agree with planed and failed. Failed is a valid state on some hypervisors.

That said, staged could make sense, if you create the VM but don't install the OS. You could also use planned for that as well however.

@DanSheps commented on GitHub (Feb 12, 2020): I agree with planed and failed. Failed is a valid state on some hypervisors. That said, staged could make sense, if you create the VM but don't install the OS. You could also use planned for that as well however.
adam commented 2025-12-29 18:27:22 +01:00
Author
Owner
Copy Link

@kobayashi commented on GitHub (Feb 12, 2020):

Yes, we can set 'Staged' as the state of pre-provisioning or pre-installing. No thought about 'Inventory'.
If no any objects here, I will additionally set 'Planned' and 'Failed'. ('Staged' is already there)

  • Planned
  • Staged
  • Failed

And color labels should be the same as device. So like this

  • Active (color: success)
  • Staged (color: primary)
  • Offline (color: warning)
  • Planned (color: info)
  • Failed (color: danger)
  • Decommissioning (color: warning)
@kobayashi commented on GitHub (Feb 12, 2020): Yes, we can set 'Staged' as the state of pre-provisioning or pre-installing. No thought about 'Inventory'. If no any objects here, I will additionally set 'Planned' and 'Failed'. ('Staged' is already there) - Planned - Staged - Failed And color labels should be the same as device. So like this - Active (color: success) - Staged (color: primary) - Offline (color: warning) - Planned (color: info) - Failed (color: danger) - Decommissioning (color: warning)
adam commented 2025-12-29 18:27:22 +01:00
Author
Owner
Copy Link

@netsandbox commented on GitHub (Feb 12, 2020):

I'm with @nathbooth that the status for devices and virtual machines should be the same.
Also with the last comment from @kobayashi, only Inventory is then missing for virtual machines.

What is status Inventory used for devices?

I can think of status Inventory for devices and virtual machines as servers, which are online, but you don't want to run Ansible playbooks agains them, if you use NetBox as inventory for Ansible.

@netsandbox commented on GitHub (Feb 12, 2020): I'm with @nathbooth that the status for devices and virtual machines should be the same. Also with the last comment from @kobayashi, only Inventory is then missing for virtual machines. What is status Inventory used for devices? I can think of status Inventory for devices and virtual machines as servers, which are online, but you don't want to run Ansible playbooks agains them, if you use NetBox as inventory for Ansible.
adam commented 2025-12-29 18:27:22 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 12, 2020):

The "inventory" status implies that the physical device is available for deployment but has not been brought online or configured. (Not to be confused with "inventory" from the Ansible vernacular.)

@jeremystretch commented on GitHub (Feb 12, 2020): The "inventory" status implies that the physical device is available for deployment but has not been brought online or configured. (Not to be confused with "inventory" from the Ansible vernacular.)
adam commented 2025-12-29 18:27:22 +01:00
Author
Owner
Copy Link

@vsvetlov commented on GitHub (Feb 12, 2020):

I think the status attributes are primarily used to reflect workflow for specific type of object.
Every company has its own workflow process to track the lifecycle of devices and virtual machines. So it is better to have more choices or make it customizable. The same can be applied for VLANs and prefixes.
The one object that missed is device interface. It is quite difficult to track interface status during automation workflow. This is why there were so many requests to implement custom fields for interfaces.
Yes, it is possible with tags. But it is really inconvinient to track status of different objects using different features of the application. I can submit a request to implement statuses for interface.

@vsvetlov commented on GitHub (Feb 12, 2020): I think the status attributes are primarily used to reflect workflow for specific type of object. Every company has its own workflow process to track the lifecycle of devices and virtual machines. So it is better to have more choices or make it customizable. The same can be applied for VLANs and prefixes. The one object that missed is device interface. It is quite difficult to track interface status during automation workflow. This is why there were so many requests to implement custom fields for interfaces. Yes, it is possible with tags. But it is really inconvinient to track status of different objects using different features of the application. I can submit a request to implement statuses for interface.
adam commented 2025-12-29 18:27:22 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 12, 2020):

@vsvetlov This issue is limited to virtual machine statuses. Let's keep the conversation focused on that please.

@jeremystretch commented on GitHub (Feb 12, 2020): @vsvetlov This issue is limited to virtual machine statuses. Let's keep the conversation focused on that please.
adam commented 2025-12-29 18:27:22 +01:00
Author
Owner
Copy Link

@nathbooth commented on GitHub (Feb 12, 2020):

I feel that the current status is quite subjective. I.e. the ‘inventory’ status @jeremystretch described above sounds more like planned. It’s probably pragmatic that we update the wiki with some suggested definitions.
For me inventory makes more sense for a device that is stateless or who’s state is unknown.
Then you have:
-Planned: intending that it will exist in future
-Staged: has been powered on and booted with barebones configuration
-Active: fully provisioned
-Failed: object has failed
-Offline: object is offline
-Decomissioning: pending or has been removed

I think all of the above bar inventory can apply to both devices and vm’s.

@nathbooth commented on GitHub (Feb 12, 2020): I feel that the current status is quite subjective. I.e. the ‘inventory’ status @jeremystretch described above sounds more like planned. It’s probably pragmatic that we update the wiki with some suggested definitions. For me inventory makes more sense for a device that is stateless or who’s state is unknown. Then you have: -Planned: intending that it will exist in future -Staged: has been powered on and booted with barebones configuration -Active: fully provisioned -Failed: object has failed -Offline: object is offline -Decomissioning: pending or has been removed I think all of the above bar inventory can apply to both devices and vm’s.
adam commented 2025-12-29 18:27:22 +01:00
Author
Owner
Copy Link

@kobayashi commented on GitHub (Feb 12, 2020):

For my case, I set 'Inventory' to a device just to be stocked in a rack. So 'Inventory' for virtual machine is not applicable to me because no such case in a virtual machine. I think it's ok to add the status if giving an usecase.

@kobayashi commented on GitHub (Feb 12, 2020): For my case, I set 'Inventory' to a device just to be stocked in a rack. So 'Inventory' for virtual machine is not applicable to me because no such case in a virtual machine. I think it's ok to add the status if giving an usecase.
adam commented 2025-12-29 18:27:22 +01:00
Author
Owner
Copy Link

@nathbooth commented on GitHub (Feb 12, 2020):

I would agree that inventory isn’t required for virtual machines, I was more musing that an informal definition would help

@nathbooth commented on GitHub (Feb 12, 2020): I would agree that inventory isn’t required for virtual machines, I was more musing that an informal definition would help
adam commented 2025-12-29 18:27:22 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 12, 2020):

Changing this back to "accepted" with the following statuses:

  • Planned
  • Staged
  • Active
  • Offline
  • Decommissioning
  • Failed
@jeremystretch commented on GitHub (Feb 12, 2020): Changing this back to "accepted" with the following statuses: * Planned * Staged * Active * Offline * Decommissioning * Failed
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#3275
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?