kubevirt/kubevirt

What happened: With the RerunOnFailure RunStrategy , if the associated PVC is deleted and recreated after vm stopped, the status will become WaitingForVolumeBinding. What you expected to happen: I executed the virtctl stop xxx command, and it should remain stopped even though the PVC has been modified. How to reproduce it (as minimally and precisely as possible): 1.vm configure spec: runStrategy: RerunOnFailure 2.Stopped the vm 3.Delete the existing PVC and create a new one.And the vm will be WaitingForVolumeBinding. Additional context: Environment: KubeVirt version (use virtctl version): N/A Kubernetes version (use kubectl version): N/A VM or VMI specifications: N/A Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): N/A Kernel (e.g. uname -a): N/A Install tools: N/A Others: N/A

Is your feature request related to a problem? Please describe: KubeVirt's core gRPC services use a legacy pattern of embedding errors in proto response messages via success bool and message string fields[1][2], bypassing gRPC's standard error model[3] entirely. Server methods return (response, nil) in the majority of cases, forcing clients to check both the gRPC error and Response.Success to determine if a client call failed. This means gRPC interceptors cannot observe application errors, error handling is incosistent across services (newer ones like plugin hooks for example already user proper status codes while older services don't). [1] kubevirt/pkg/handler-launcher-com/cmd/v1/cmd.proto Lines 150 to 153 in 7f6aafd message Response { bool success = 1; string message = 2;

Is your feature request related to a problem? Please describe: KubeVirt currently uses https://github.com/go-kit/log as the backend for its custom logging wrapper in staging/src/kubevirt.io/client-go/log. go-kit/log has not had a release since May 2022 and shows minimal maintenance activity. The broader go-kit ecosystem is effectively in maintenance mode with little maintainer engagement. Moreover, the adoption of go-kit and the creation of client-go/log was done at a time where structured logging for k8s controllers was not yet standardized, https://github.com/go-logr/logr which has since become the ecosystem-wide interface used by controller-runtime and client-go did not exist yet. Such transition would also open the path to a potential gradual migration to controller-runtime in KubeVirt. Describe the solution you'd like: Replace go-kit/log as the logging backend inside client-go/log/log.go with logr paired with a well-maintained backend such as https://github.com/kubernetes/klog or

Is your feature request related to a problem? Please describe: The KubeVirt CR has two independent imagePullPolicy fields: spec.imagePullPolicy — used by virt-operator for infrastructure deployments (virt-api, virt-controller, virt-handler, etc.) spec.configuration.imagePullPolicy — used for KubeVirt-owned containers in user workload pods (compute, guest-console-log, network binding sidecars, etc.) Note: user-supplied images (container disks, kernel boot) have their own per-volume imagePullPolicy inline in the volume spec, which is reasonable since the user controls those images. This is confusing for users because: Neither field was documented to explain what it controls or how it differs from the other They default independently (both to IfNotPresent) with no fallback between them A user setting spec.imagePullPolicy would reasonably expect it to apply everywhere, not just to infrastructure Historically, spec.imagePullPolicy was introduced with the operator (2018), and spec.co

Is your feature request related to a problem? Please describe: In many cases, one feature gate depends on another feature. So if you know that for example I want so-and-so feature enabled, it's not always obvious which feature gates you must also enable for the desired featuregate to fully be activated. Describe the solution you'd like: This issue proposes adding another field to the FeatureGate struct as defined in feature-gates.go to track the feature's dependant featuregates: type FeatureGate struct { Name string State State VmiSpecUsed func(spec *v1.VirtualMachineInstanceSpec) bool Message string } If a user enables a feature gate without enabling all dependencies, ideally I would like there to be a clear message in the logs about which feature gates the feature gate the user wants to enable depends on so that the user knows exactly which feature gates they must also enable. Side benefit is: not accidentally GAing a feature gate that still has Beta/