Status Decommissioning missing for virtual machines

[netsandbox]

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

[kobayashi]

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]

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

[nathbooth]

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

• Planned
• Staged
• Failed
• Inventory

[jeremystretch]

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.

[DanSheps]

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.

[kobayashi]

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)

[netsandbox]

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.

[jeremystretch]

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.)

[vsvetlov]

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.

[jeremystretch]

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

[nathbooth]

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.

[kobayashi]

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.

[nathbooth]

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

[jeremystretch]

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

• Planned
• Staged
• Active
• Offline
• Decommissioning
• Failed