multus: bump to multus-v4 (thick plugin)

[maiqueb]

What this PR does / why we need it:
The multus bump script was updated to:

• use a different multus manifest - multus-daemonset-thick.yml
• ignore comments in the manifest file. Comments in the manifests broke the yaml-utils::split_yaml_by_seperator function.

Special notes for your reviewer:

Release note:

Consume multus v4, which operates as a thick plugin.

[maiqueb]

/test pull-e2e-cluster-network-addons-operator-kubemacpool-functests

[RamLavi]

just some preliminary comments, feel free to disregard if it's not helpful to you :)

[maiqueb]

/test pull-e2e-cluster-network-addons-operator-macvtap-cni-functests

[maiqueb]

Had to rebase latest master to address the macvtap issue.

[maiqueb]

We're being held back for k8snetworkplumbingwg/multus-cni#944 ...

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[maiqueb]

/cc @phoracek

[RamLavi]

Can you move the last commit multus, temporal hack: use untagged multus version to be the first?
then the "old first commit" aka multus: bump to multus-v4 (thick plugin) will only deal with the changes made to the bump script and it's outputs

[maiqueb]

Can you move the last commit multus, temporal hack: use untagged multus version to be the first? then the "old first commit" aka multus: bump to multus-v4 (thick plugin) will only deal with the changes made to the bump script and it's outputs

I can, but I don't see the advantage. What does that achieve ?

[RamLavi]

Can you move the last commit multus, temporal hack: use untagged multus version to be the first? then the "old first commit" aka multus: bump to multus-v4 (thick plugin) will only deal with the changes made to the bump script and it's outputs

I can, but I don't see the advantage. What does that achieve ?

Since commits in this repo are squashed to 1 commit per PR, then it doesn't really matter, but if someone looks back at this PR then the first commit seems to use a wrong commit, that will surely break cause the bump fails to retrieve the tag --> SHA digest..
My intent is only to make it more readable, but if it is to much of a hustle, I won't insist

[maiqueb]

Can you move the last commit multus, temporal hack: use untagged multus version to be the first? then the "old first commit" aka multus: bump to multus-v4 (thick plugin) will only deal with the changes made to the bump script and it's outputs

I can, but I don't see the advantage. What does that achieve ?

Since commits in this repo are squashed to 1 commit per PR, then it doesn't really matter, but if someone looks back at this PR then the first commit seems to use a wrong commit, that will surely break cause the bump fails to retrieve the tag --> SHA digest.. My intent is only to make it more readable, but if it is to much of a hustle, I won't insist

The first commit is the correct one - it uses the tag, that unfortunately has a bug. The top most commit is the patched workaround for us to move forward.

I'd prefer to leave this as is.
@RamLavi

[RamLavi]

I'd prefer to leave this as is.

Ok
/lgtm

[RamLavi]

@qinqon can you have a look as well?

[qinqon]

/lgtm
/approve

[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 [qinqon]

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