cert-manager-operator
cert-manager-operator copied to clipboard
openshift
Why is the cert-manager-operator for Red Hat not AllNamespaces
During tech preview, I was able to install cert-manager-operator in AllNamespaces mode. When was this support removed and why?
The CNCF cert-manager-operator is only installable in AllNamespaces mode, so why does the Red Hat one deviate from this?
Additionally, cert-manager is a cluster wide service, and there is a limitation that there cannot be 2 active cert-manager-controllers on a cluster simultaneously since cert-manager never implemented this functionality properly https://github.com/cert-manager/cert-manager/issues/2525.
So with Red Hat cert-manager not restricting the install mode to only AllNamespaces, isn't there a risk that different users on a cluster accidentally install Red Hat cert-manager multiple times, leading to multiple active cert-manager-controllers?
I actually have run into this today. When you install in multiple namespaces, the Deployment.app for the operator conflicts, and is constantly updating.
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle rotten /remove-lifecycle stale
While it seems most currently-developed Operators are moving to AllNamespaces mode, it is quite disruptive to change anything like this mid-channel version. Documenting why this namespace method was used could be useful, but otherwise I'm happy to see this close.
The controller deployed by RH Cert Manager operator has cluster-wide permissions and visibility, as does the upstream CNCF/Jetstack Cert-Manager on which this is based. Not installing the Cert-Manager in AllNamespaces mode does not change this. Allowing installation in anything but AllNamespaces mode is misleading. This is the essence of the bug
On further review of this, I believe that the desire on behalf of Red Hat was to install the operator in a namespace other than openshift-operators even though it is cluster scoped (essentially AllNamespace Mode). Taking the default, the operator is installed in the cert-manager-operator namespace with its deployed resources running in the cert-manager namespace. So this operator's payload does indeed have cluster scoped visibility and control (look at its clusterrolebindings). The issue is in the OperatorHub dialog misrepresentation that installing Cert-Manager in a named namespace implies that it only watches and controls its CRs in that installed namespace. Regardless of where its installed, it is essentially running in AllNamespace mode.
The OperatorHub DIalog is just WRONG with respect to this operator/payload.
In addition because it is not installed in openshift-operators (currently the right place for all operators installed in AllNamespace mode) views of the installed operators in other namespaces in the OperatorHub do not show the RH Cert-Manager operator even though it has control in those namespaces. My guess is that only operator installed in in the openshift-operators namespace are seen as as installed operator in every other namespace. Again this is misleading.
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.
/close
@openshift-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting
/reopen. Mark the issue as fresh by commenting/remove-lifecycle rotten. Exclude this issue from closing again by commenting/lifecycle frozen./close
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.
![openshift-ci[bot] avatar](https://avatars.githubusercontent.com/in/91280?v=4 "Published by a pub.dev verified publisher"){kind=small}
It does not look like this issue was resolved, and in a recent discussion with the Red Hat Cert Manager team I was under the impression a fix was in progress.
/reopen
/remove-lifecycle rotten
@griffindvs: You can't reopen an issue/PR unless you authored it or you are a collaborator.
In response to this:
It does not look like this issue was resolved, and in a recent discussion with the Red Hat Cert Manager team I was under the impression a fix was in progress.
/reopen
/remove-lifecycle rotten
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.
@griffindvs as this is affecting a productized component, I would suggest opening an issue at https://issues.redhat.com for tracking purposes. Issues in GitHub are generally not tracked as strongly.
Suggest starting at https://issues.redhat.com/projects/CM/summary