Operator broke on OKD and Kubernetes

[aelbarkani]

There was a change in the image which breaks the operator for non Redhat users: https://github.com/redhat-cop/namespace-configuration-operator/blob/84b10314ed8ebb6cde16e4f08a2c59fcca66b801/config/default/manager_auth_proxy_patch.yaml#L13

[aelbarkani]

Actually I see the same problem in all redhat-cop operators @raffaelespazzoli, so I'll just report the issue here instead of spamming you in all the other repos :)

[garethahealy]

@aelbarkani ; i presume the issue is you don't have auth to pull that image?

if so, the free developer subscription might help and give you access to the pull secret:

• https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-developer-subscription-now-available
• https://access.redhat.com/terms-based-registry/

*not tested it myself

[aelbarkani]

Thanks @garethahealy, yes that is the issue. I assume there is policy change in terms of image distribution for redhat-cop operators ?

[raffaelespazzoli]

hello, @aelbarkani the requirements for the rbac-proxy image are the following:

1. must be maintained
2. must be published as a multiarch To these you are adding that it should be accessible without credentials.

We didn't find an image that aligned with those requirements, so we asked the operator framework team to support one. They said they were not interested.

The image in registry.redhat.io/openshift4/ose-kube-rbac-proxy seemed the best compromise as we assume that these operators are installed in OCP therefore one will have the credentials. If installing the operators outside OCP, one should use the helm charts which use the google-maintained image.

I'm open to changing the image we use with OLM as long as we find one that meets the above requirements.

[vrutkovs]

We didn't find an image that aligned with those requirements, so we asked the operator framework team to support one. They said they were not interested.

Maybe quay.io/openshift/origin-kube-rbac-proxy would fit here? Not entirely sure if its multiarch though

[raffaelespazzoli]

That image seems maintained and rebuilt often. however there is no multiarch support at the moment. Do you know where the source is? Maybe we can open an RFE at that repo.

On Thu, Sep 2, 2021 at 4:58 AM Vadim Rutkovsky @.***> wrote:

We didn't find an image that aligned with those requirements, so we asked the operator framework team to support one. They said they were not interested.

Maybe quay.io/openshift/origin-kube-rbac-proxy would fit here? Not entirely sure if its multiarch though

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/redhat-cop/namespace-configuration-operator/issues/118#issuecomment-911416955, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPERXD2D7XA7KCMEVNSDG3T744ERANCNFSM5DAEQB6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- ciao/bye Raffaele

[vrutkovs]

Its a CI build of kube-rbac-proxy for OCP, so the source is the same as for registry.redhat.io/openshift4/ose-kube-rbac-proxy - but its not trivial to find multiarch, as OCP CI doesn't make multiarch builds (at least it doesn't publish them as manifest lists)

Perhaps the operator should have an option to redefine the image pullspec?

[nevidanniu]

@raffaelespazzoli is it more important then availability of operators? Currently a lot of community operators (which by design should be anonymous accessible) are broken because they can't access private redhat repo, and there is no workaround to fix it except give up and never use community operators if they may be such easily broken and no one care.

[raffaelespazzoli]

@nevidanniu what image would you use? The OCP users want an image that comes from red hat or quay and that it is maintained for security reasons. The operator needs an image that is multiarch. The community wants an image that is not protected by authentication.

which image should I use? I'm open to suggestions.

The solution for the community for now is to install via helm.
I'm working with engineering to see if we can find a solution to this issue.

[nevidanniu]

The solution for the community for now is to install via helm. I'm working with engineering to see if we can find a solution to this issue.

Then cut out all these operators from community operators as they are NOT public available anymore. Currently community installs OKD, tries to install your operators (that are available out of box) and get failed. What they should think about OKD and RH if their own software and repos doesn't work?

[raffaelespazzoli]

@nevidanniu I think your point is valid, but I don't control that part of the process. My understanding is the following: operator for OCP (downstream) should be released here: https://github.com/redhat-openshift-ecosystem/community-operators-prod , while operator for kubernetes (upstream) should be released here: https://github.com/k8s-operatorhub/community-operators/tree/main/operators . We release the CoP operators only upstream, we are not ready for downstream in many ways, not just because of the image authentication issue. It sounds like the problem you are pointing out is that the OKD operator catalog is built from the downstream repo instead of the upstream repo. Whether that is correct or not is not for me to say.

[vrutkovs]

I disagree with community operators using non-public images. First, it puts a barrier to contribution, second that means the operator would be best released on the Marketplace. Especially when the operator has been on community operators catalog for quite a long time already.

Sacrificing a multiarch support seems to be a small price to pay, until we figure out how to add it back

[raffaelespazzoli]

@vrutkovs we should consider sacrificing multi-arc for now like you say. Before we do that, I want to see if someone in the OKD image is willing to maintain a open multiarch rbac-proxy image.

[aelbarkani]

I agree with both, sacrificing multi-arch is probably the best short term option here.

[vrutkovs]

Before we do that, I want to see if someone in the OKD image is willing to maintain a open multiarch rbac-proxy image.

There are plans to make arm64-compatible build of OKD, so multiarch version of this image would eventually be released

[raffaelespazzoli]

@vrutkovs any news on multiarch support for OKD?

[vrutkovs]

Its planned, but we have no release date for it.

In any case, a broken version of this operator is already available in OKD 4.7 and this version won't get multiarch support - so this needs to be resolved urgently