Bug 1994604

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