Feature Overview (aka. Goal Summary)

Today, if the KubeVirt VMs created by cluster-api-provider-kubevirt (capk) fail to be created, provisioned, or run for any reason, that information is not currently passed back to the capi ecosystem. This leaves users of HCP KubeVirt clueless as to what the issue might be when looking at the NodePool object to understand why worker nodes are not coming online.

Goals (aka. expected user outcomes)

Errors detected during VM creation, provisioning, scheduling and runtime need to be reported back to the NodePool object.

Requirements (aka. Acceptance Criteria):

A list of specific needs or objectives that a feature must deliver in order to be considered complete. Be sure to include nonfunctional requirements such as security, reliability, performance, maintainability, scalability, usability, etc. Initial completion during Refinement status.

Use Cases (Optional):

• As an HCP KubeVirt cluster creator, I want to be able to easily discover KubeVirt VM issues are occurring by inspecting the NodePool object.