Feature Overview (aka. Goal Summary)  

OLM v1 supports operators packaged in registry+v1 bundle format, including those defining webhooks within their ClusterServiceVersion resources.

Goals (aka. expected user outcomes)

• Users can rely on OLM v1 to manage operators packaged in registry+v1 bundle format, including those with webhooks.

• Operator authors can rely on OLM v1 to manage the lifecycle of webhooks included in their registry+v1 bundle-packaged operators without modifications.

• Users can rely on OLM v1 to detect webhook misconfigurations, such as webhooks reporting no available endpoints, and troubleshoot the underlying Service's Pods.

Background

To foster a thriving operator ecosystem and protect existing investments, OLM v1 aims to support operators packaged in the registry+v1 bundle format, including those with webhooks.  By preserving compatibility with the current operator landscape, we ensure a smooth transition for operators and end-users to the OLM platform.  This approach not only accelerates OLM adoption but also safeguards the stability and functionality of existing workloads on the OpenShift clusters.

Requirements (aka. Acceptance Criteria):

• Webhook definition: OLM v1 parses and understands webhook definitions within the CSV object.

• Webhook creation: OLM v1 deploys webhooks based on the definition within the CSV object (ValidatingWebhookConfiguration, MutatingWebhookConfiguration, ConversionWebhookConfiguration) and integration with the Kubernetes API server.

• Webhook updates: OLM v1 handles the updates to webhook configurations when the bundle/CSV is modified during the upgrade.

• Webhook Deletion: OLM v1 cleans up webhook resources for extension/operator deletion.

• Certificate management: OLM v1 manages the lifecycle of webhook certificates, including creation and rotation.

• Error handling and troubleshooting: OLM v1 detects webhook misconfigurations, such as webhooks reporting no available endpoints, aiding in troubleshooting the underlying Service's Pods.

Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

Use Cases (Optional):

Include use case diagrams, main success scenarios, alternative flow scenarios.  Initial completion during Refinement status.

<your text here>

Open Questions

• OLM v0 has the concept of "ensuring that the webhook only acts upon namespaces that match the Operator group that the Operator is deployed in", how do we want to address this in OLM v1?
  • Should webhook resources be strictly cluster-scoped, or should we explore namespace-scoped support similar to watch scope templating?

Out of Scope

High-level list of items that are out of scope.  Initial completion during Refinement status.

<your text here>

Documentation Considerations

Provide information that needs to be considered and planned so that documentation will meet customer needs.  If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

• The steps for managing the lifecycle of operators packaged in registry+v1 bundles with webhooks.

• The steps for troubleshooting webhook misconfigurations.

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact?  What interoperability test scenarios should be factored by the layered products?  Initial completion during Refinement status.

<your text here>