Consider switching to kubevirt.io/api from kubevirt.io/client-go

[rmohr]

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

/kind enhancement

What happened:

kubevirt.io/client-go pulls in tons of dependencies and makes it hard to integrate with other kubernetes related golang packages.

What you expected to happen:

Starting with 0.48 we will have tagged releases of just our APIs at https://github.com/kubevirt/api and https://github.com/kubevirt/containerized-data-importer-api which can be used like described at https://github.com/kubevirt/kubevirt/blob/f4ff1cabebfd98f1f7c72bc1b1c5ab15fd6b3457/staging/src/kubevirt.io/api/README.md.

This pulls in drastically less dependencies and will make dependency resolution in the future much simpler for you.

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• HCO version (use oc get csv -n kubevirt-hyperconverged):
• Kubernetes version (use kubectl version):
• Cloud provider or hardware configuration:
• Install tools:
• Others:

[nunnatsa]

@rmohr - Can we assume the same tag as the KubeVirt version starting from v0.48.0, as it's done in CDI?

It will be safer to bump the api together with KubeVirt version, using the current bot.

[rmohr]

@nunnatsa yes you can expect matching tags. Note that since our API is backward compatible, it should also be possible without much issues to just go ahead and adopt main early if necessary by just not using new api fields (just that you know, not and advise :) ).