operator-lifecycle-manager
operator-lifecycle-manager copied to clipboard
operator-framework
Can the OLM operator be more relaxed about admission controllers and let other components to also manage them?
Feature Request
Is your feature request related to a problem? Please describe. Hi!
I'm currently working on publishing a Knative Eventing Source to OLM, and I wasn't able to configure the admission webhooks properly.
This happens because both Knative and OLM want to manage the certificates and the webhooks. This is the classic situation where one controller could be more relaxed about its managing object. :)
I'm wondering if it would be feasible if OLM could be more relaxed about the admission webhooks, especially regarding the CA management. This way, other components in the architecture could manage the certs by themselves (mounting, fetching the target secret, updating the rules, etc.). Some platforms might need to have more control over it.
Describe the solution you'd like OLM Operator could not generate and manage the target certificate and specific aspects of the admission webhook, such as the rules and the target service.
Incorporates https://github.com/operator-framework/operator-lifecycle-manager/issues/1805. I think the mentioned issue could handle this issue, but I am not sure about other aspects of the webhook. For example, would it make sense for the OLM to step back? Just create the initial object and let other components in the architecture manage them.
Hi @ricardozanini
thanks for raising this. #1805 is about delegating the certification management to another stack but it would still have OLM trigger requesting and assigning the certs. It sounds like in your proposal OLM should offer not to do that at all - is that correct? What's left then is simply applying the webhook configuration?
Hi @dmesser! Many thanks for the quick response. Yes, I propose to let another component of the architecture to handle the webhook management and reconciliation. OLM would just ensure that the webhook is there and configured with the correct service and deployment. This approach would likely increase the compatibility with operators that need to handle the admission webhooks, including certification management. What does that sound like to you?
This sounds like we would just support you shipping the webhook related manifests as part of the bundle and apply them as is, instead of making the webhooks part of the CSV.
cc @kevinrizza @awgreene
Hi I am facing a similar issue in which I have to assign different webhooks to different services. I see that this has already been reported as a feature request. What will be the ETA of this feature? As my operator has been certified by Redhat OpenShift and is on operator-hub, it's not configured correctly due to this issue.
@dmesser @awgreene @kevinrizza Are there any updates related to this?
