Reporting of VM error states

[Zvi Cahana]

We've recently introduced [1] a new `.status.printableStatus` field in the VM CRD.

This field is designated to provide a human-readable status about the current state of the VM, and is also included as a new STATUS column in the tabular output of `kubectl get vms`.

As of now, the reported states are mostly "normal" lifecycle states such as Stopped or Running (see [2] for a list of states).

Now, we'd like to expand that list with various error states the VM may run into (such as ErrImagePull or FailedUnschedulable), with the goal of having a visible and easy to spot error reporting.

In the following document [3], I've compiled a list of various error states, including how we currently report them with via phases, conditions and events of involved objects, as well as what additional reporting mechanisms are proposed.

I'd appreciate your feedback about the relevancy/usefulness of the various error states, as well as suggestions for additional error states` which are useful to report.

[1] https://github.com/kubevirt/kubevirt/pull/5528

[2] https://kubevirt.io/user-guide/architecture/#controller-status

[3] https://docs.google.com/spreadsheets/d/14Py_jVmFas_O7OUGtSY8dKK_4I5E3ZkEy7ii1GRj98g/edit?usp=sharing

[Kevin Wiesmueller]

I'm working on readinessProbes and we just merged https://github.com/kubevirt/kubevirt/pull/5038
The next qemu probe on the list is qemu-ping marking the pod as unready if the guest agent does not respond.
Maybe the readinessProbe could be reported in a better way on this status as well.
Not sure on how it fits into your document yet.

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/7defbdfa-ae8f-4bd5-9215-a4b6bc6222dan%40googlegroups.com.

[Zvi Cahana]

Actually, VM readiness (regardless of the exec/ping/http mechanism) is a significant aspect on its own, and might be worthy of a dedicated READY column, similar to Pods, Deployments and StatefulSets. What do you think?

[Kevin Wiesmueller]

Yeah, it could be a dedicated Ready field.
I know your document is mainly about error states, but my first thought was that we could write more detailed status to it.
Like, Provisioning, Booting and Booted if we have the relevant data (like guest status etc.).

To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/6262add8-c10f-40af-a77b-21e92cc58a8cn%40googlegroups.com.

[Zvi Cahana]

There's already a Provisioning status, used for when DVs/PVCs are being provisioned. Did you mean anything else by Provisioning?
Same for Booted, we already have a Running status which is quite similar.

Booting is an interesting status to report, but I'm afraid it would be hard to draw the line on where the boot phase ends, especially considering this can differ substantially between different OS's.
From an application perspective, I think that a READY indication would cover most cases where a consumer needs to know when the VM has done booting and is ready to serve. But for these other cases, I'd be happy to hear thoughts on how to detect "Booting".

[James Gu]

I know this is more than 2 years old. Wanted to check if there was any follow up or development regarding the additional error states?