Description of problem: Add a feature to virtctl to check client and server version alignment and to print an informative message indicating this with the versions displayed in the message Version-Release number of selected component (if applicable): v0.44.0 How reproducible: Steps to Reproduce: 1. When running any virtctl command check that the client and server versions are aligned and display an informative message indicating that the client and server versions are not aligned. The versions of both the client and server should be displayed too 2. 3. Actual results: No check is done Expected results: An informative message should be displayed indicating that the client and server versions are not aligned. The versions of both the client and server should be displayed Additional info: An old bug requiring the versions to be aligned exists: https://bugzilla.redhat.com/show_bug.cgi?id=1647513
This requested information is returned if the user types: virtctl version It appears that the request here is to do this check for literally every invocation of any virtctl command? It's not clear to me what the benefit of doing this is. If compatibility issues manifest from a version mismatch, those scenarios are most likely a bug and should be dealt with individually. I'm of the opinion that formally doing this check in all cases can actually cause confusion. It implies to end users that there's some benefit or requirement for client and server versions to match, and that's simply not the case. Can you please clarify why this would be helpful? Does the "virtctl version" subcommand meet your needs? e.g. for the instances where you need to actually verify what versions are in use?
I've requested to file the rfe. In the past we had bugs where outdated virtctl versions lead to bugs (iirc when we were changing the way how the serial console was done). There are other cases where virtctl is gaining new features. Thus a common pattern that is seen - i.e. in minikube and crc - is to compare the client version to the server version, and in case of a newer server version there is a small notice that (likely) there is also a new client version available. So, this is not about running "virtctl version" on every "virtctl" invocation, but letting the users know when they should be updating virtctl to avoid problems. Does this help?
If this check shouldn't necessarily be done on every command invocation, could you please clarify when you think that this check should be done?
What approach do other tools in the kube verse take here?
How often? Upon errors! Once a day?
Currently it will shows the warning message only if an error occurs with the command. Basically, the logic is: if an error occurs executing the command we check the server and client versions; if they don't are compatible (checking only major and minor version, skipping patch version) the command line shows the warning suggesting that (maybe) the problem is related to incompatible versions.
checked with v4.11.0-339 no message is displayed on version missmatch [akrgupta@ovpn-9-60 auth]$ virtctl44 version Client Version: version.Info{GitVersion:"v0.44.0", GitCommit:"46411f3bb6568c14b23f53b4c5f7e54a63aec2a0", GitTreeState:"clean", BuildDate:"2021-08-09T14:30:18Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{GitVersion:"v0.53.0-55-ga3aaf1ace", GitCommit:"a3aaf1ace40c44c9dafaf2c091851d5cdb829fd7", GitTreeState:"clean", BuildDate:"2022-05-11T17:53:40Z", GoVersion:"go1.17.5", Compiler:"gc", Platform:"linux/amd64"}
In order to avoid too aggressive messages (warning for every interaction), the version mismatch will be shown only if an error occurs with the command you run.
Verified with v4.11.0-339 [akrgupta@fedora bin]$ virtctl55 start vm1 You are using a client virtctl version that is different from the KubeVirt version running in the cluster Client Version: v0.52.0 Server Version: v0.53.0-55-ga3aaf1ace Error starting VirtualMachine virtualmachine.kubevirt.io "vm1" not found
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: OpenShift Virtualization 4.11.0 Images security and bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:6526
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days