cluster: Allow kubevirtci tag overriding

[oshoval]

What this PR does / why we need it: It is helpful either manually or for example when used from CNAO, to use same tag of the cluster that CNAO deployed. Otherwise a kubevirtci tag mismatch can cause failures once running KMP e2e tests from CNAO.

Special notes for your reviewer:

Release note:

None

[kubevirt-bot]

Skipping CI for Draft Pull Request. If you want CI signal for your change, please convert it to an actual PR. You can still manually trigger a test run with /test all

[oshoval]

/cc @RamLavi we need this (+ release once it is merged please) so we can bump kubevirtci on CNAO otherwise if the cluster kubevirtci tag CNAO deployed is different then the kubevirtci helper scripts that KMP uses it can product failures. with this small change, the tag CNAO uses will be also used whenever needed when CNAO runs KMP e2e tests (which is the correct thing to do, regardless of bumping)

We need this fix on all repos, so far did on OVS and KMP, where i already so problems where it was missing.

[oshoval]

/test pull-kubemacpool-e2e-k8s

[oshoval]

need first to adapt bump-kubevirtci.sh

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: qinqon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/k8snetworkplumbingwg/kubemacpool/blob/main/OWNERS)~~ [qinqon] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment

[oshoval]

Thanks Can you please create a patch release 0.43.1 on main so CNAO consume it ? @phoracek @RamLavi @qinqon

It will be indeed nice when we implement mechanism to allow consuming non core related changes by CNAO, i will work on it when i have time.

[RamLavi]

@oshoval you need to backport this to release-0.43 first no?

[RamLavi]

@oshoval you need to backport this to release-0.43 first no?

oh my bad, we are already after CF on that stable branch. This change will only affect U/S, am I correct? And only the U/S dev env (i.e. the lanes etc..) right? If the answer is yes to both of the above then I assume that backporting this change is safe enough to do without getting QE to approve it and all that, but I still wonder why you would want to backport it to that stable branch - It's going GA in a few days

Perhaps you meant you want to issue a new main release (which will be minor 0.44.0 IIUC)? - in that case I'm all forward

[oshoval]

@oshoval you need to backport this to release-0.43 first no?

oh my bad, we are already after CF on that stable branch. This change will only affect U/S, am I correct? And only the U/S dev env (i.e. the lanes etc..) right? If the answer is yes to both of the above then I assume that backporting this change is safe enough to do without getting QE to approve it and all that, but I still wonder why you would want to backport it to that stable branch - It's going GA in a few days

Perhaps you meant you want to issue a new main release (which will be minor 0.44.0 IIUC)? - in that case I'm all forward

this change doesn't affect KMP at all (as it only allow external overriding the default value) we just need a main release indeed so CNAO can consume it (it will help CNAO, not KMP) ye we can use 0.44.0 if 0.43.0 is stable, in any case since CNAO main watches KMP main, the release must be on main we just need CNAO to consume it, didn't mean i want to backport it, just looked what is the last release naively

can you please create new minor 0.44.0 on main ?

Thanks

[RamLavi]

can you please create new minor 0.44.0 on main ?

https://github.com/k8snetworkplumbingwg/kubemacpool/releases/tag/v0.44.0

[oshoval]

can you please create new minor 0.44.0 on main ?

https://github.com/k8snetworkplumbingwg/kubemacpool/releases/tag/v0.44.0

Thanks !