Add an alias to KUBEVIRT_WITH_MULTUS_V3

[orelmisan]

What this PR does / why we need it:
Currently, the KUBEVIRT_WITH_MULTUS_V3 environment variable is used to specify the user's desire to directly deploy Multus v3 (not via CNAO).

In preparation for upgrading the Multus version from 3.x to 4.x, add another environment variable KUBEVIRT_WITH_MULTUS that will be used to specify the user's desire to directly deploy Multus.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:
Multus will be upgraded from v3.x to v4.x in a follow-up PR.

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• Design: A design document was considered and is present (link) or not required
• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
• Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
• Community: Announcement to kubevirt-dev was considered

Release note:

NONE

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign davidvossel for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[orelmisan]

/cc @EdDev @oshoval @nirdothan

[sourcery-ai]

Hey @orelmisan - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[oshoval]

can it be done in the same PR that update to multus V4 ?
this is confusing and kubevirt (maybe also project-infra) still uses KUBEVIRT_WITH_MULTUS_V3
if a release of kubevirtci is released in the middle it can do theoretical noise, and i dont see how crucial it is
to have it in a separated PR in this specific case please

[orelmisan]

can it be done in the same PR that update to multus V4 ? this is confusing and kubevirt (maybe also project-infra) still uses KUBEVIRT_WITH_MULTUS_V3 if a release of kubevirtci is released in the middle it can do theoretical noise, and i dont see how crucial it is to have it in a separated PR in this specific case please

Because there is a delicate dance involving kubevirt, kubevirtci and project-infra, this has to be performed in little steps in order to keep everything running.

[orelmisan]

Additionally, AFAICT, there wasn't a release of kubevirtci since 2020.

[EdDev]

IMO it would be simpler if we always deploy multus directly, to avoid this question being raised.
But perhaps we should focus on this later to allow other projects to feedback on it.

Thanks.

[oshoval]

Additionally, AFAICT, there wasn't a release of kubevirtci since 2020.

there is a release on each PR, look on the tags

we cant change those flags in steps, if it can break

[orelmisan]

IMO it would be simpler if we always deploy multus directly, to avoid this question being raised. But perhaps we should focus on this later to allow other projects to feedback on it.

Thanks.

This is the overall plan, the execution is done in little steps in order to keep everything working.

[orelmisan]

Additionally, AFAICT, there wasn't a release of kubevirtci since 2020.

there is a release on each PR, look on the tags

we cant change those flags in steps, if it can break

This is the reason an environment variable is added in addition to the existing one - so nothing will break until it is properly consumed.

[oshoval]

This is the reason an environment variable is added in addition to the existing one - so nothing will break until it is properly consumed.

Yes and no, it is indeed added side by side as affecting the config, but replaced on the check-up already
anyhow counting on you

[orelmisan]

This is the reason an environment variable is added in addition to the existing one - so nothing will break until it is properly consumed.

Yes and no, it is indeed added side by side as affecting the config, but replaced on the check-up already anyhow counting on you

Do you have a concern regarding the check-cluster-up.sh being changed?

[oshoval]

Do you have a concern regarding the check-cluster-up.sh being changed?

all good nothing major

[kubevirt-bot]

@orelmisan: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
check-provision-k8s-1.31-s390x	a68e64c	link	false	/test check-provision-k8s-1.31-s390x

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.