The origin-kube-rbac-proxy image is not compatible with the s390x

[ashokpariya0]

architecture. This change deploys an image that is multi arch supported.

What this PR does / why we need it:
The origin-kube-rbac-proxy image is not compatible with the s390x architecture.
This change deploys an image that is multi arch supported and this will enable
CNAO on s390x architecture to get started and test CNAO supported CNI plugins

Special notes for your reviewer:
proposed image(https://quay.io/repository/brancz/kube-rbac-proxy/manifest/sha256:e6a323504999b2a4d2a6bf94f8580a050378eba0900fd31335cf9df5787d9a9b) is built from parent repo of https://github.com/openshift/kube-rbac-proxy.

Release note:

None

[kubevirt-bot]

Hi @ashokpariya0. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

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.

[ashokpariya0]

Please check issue (#1916) for details.

[oshoval]

Thanks
You need please also the 2nd change that you have here
#1914

[oshoval]

The word architecture should be part of the title, please make the title shorter on PR and commit
and then update the PR desc accordingly.

[ashokpariya0]

Thanks You need please also the 2nd change that you have here #1914

I was thinking to not to change kubemacpool-mac-controller-manager image with proposed image now as this is not needed for now, Will follow up issue with on https://github.com/openshift/kube-rbac-proxy, Is that okay? What do you think?

[oshoval]

It won't work otherwise
CNAO deploy the image both for itself and for KMP
so both need to have the same expected image in the test

another ortogonal PR can change it on KMP, but this PR and KMP PR can be merged in any order
they dont affect each other (CNAO deploy KMP so it decide the images of it when it is used)

[oshoval]

Thanks

/test all

[ashokpariya0]

It won't work otherwise CNAO deploy the image both for itself and for KMP so both need to have the same expected image in the test

another ortogonal PR can change it on KMP, but this PR and KMP PR can be merged in any order they dont affect each other

Alright, It's done.

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[oshoval]

can you please change also on https://github.com/k8snetworkplumbingwg/kubemacpool?
so we will have both aligned (even that it is orthogonal it is better like that)

[ashokpariya0]

can you please change also on https://github.com/k8snetworkplumbingwg/kubemacpool? so we will have both aligned (even that it is orthogonal it is better like that)

Sure.

[oshoval]

@phoracek
would need your ack here please (once all tests pass)

all reasoning on the issue, for me it looks fine fwiw

[ashokpariya0]

/retest

[kubevirt-bot]

@ashokpariya0: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest

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.

[oshoval]

might be just a flake
https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_cluster-network-addons-operator/1917/pull-e2e-cluster-network-addons-operator-workflow-k8s/1843990810543001600

/retest

[ashokpariya0]

can you please change also on https://github.com/k8snetworkplumbingwg/kubemacpool? so we will have both aligned (even that it is orthogonal it is better like that)

Done, Please check PR.

[oshoval]

/lgtm

imo it is good to start like that, allowing CNAO operator itself to be robust and to already support the ones that are multi
and then to tackle one by one as the issue says

but lets see what @phoracek says

Thanks

[phoracek]

@oshoval I understand this new image is the real upstream of the one we used to use. I'm not against this change. I won't LGTM just because I don't know whether there any other changes needed to make the image change fit into our automation.

[ashokpariya0]

@oshoval I understand this new image is the real upstream of the one we used to use. I'm not against this change. I won't LGTM just because I don't know whether there any other changes needed to make the image change fit into our automation.

@phoracek Thank you for your feedback! I appreciate your understanding regarding the upstream image change. What steps should we take next to ensure our automation tests setup is compatible? It's important to note that without this change, we won't be able to run the CNAO operator on the s390x architecture. I’d welcome any suggestions you might have for a solution.

[phoracek]

@ashokpariya0 looking at an older PR that changed an image source https://github.com/kubevirt/cluster-network-addons-operator/pull/945/files#diff-b62a52052b6d9294695602994bd32db41de0d3c71d85ab711551874740eaf0feL42. Chances are your own PR is enough. I'm not all that familiar with the image/bump pipeline of CNAO, I would need @oshoval / @RamLavi to ack this

[oshoval]

Yep it is enough
Kube-rbac-proxy is used by CNAO itself as well (used for CNAO and KMP), so it doesn't have auto bumping atm via bump-x files
EDIT in other words there are two reasons:

1. Since CNAO also use it for both itself and KMP, it is not part of bump-x scripts, so not part of auto bumper.
2. Since we don't support for it auto update on upstream, we don't have any flow that need to be updated beside the image itself (we can add support for this in the future if required).

Thanks
/lgtm

[oshoval]

/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: oshoval

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

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