Summary

Like v0's use of Subscription, v1 needs to be able to pass configuration values to bundles

Epic Goal

Enable end-users to pass package-specific configuration to operators managed by OLM v1 by introducing an optional, schema-validated spec.config field on ClusterExtension resources and wiring that field into the registry+v1 renderer, achieving feature parity with:x

• Subscription.config in OLM v1
• Move watchNamespace configuration for Single-/OwnNamespace into bundle config
• Helm charts’ values / custom values.yaml idiom 

Why is this important?

1. User experience parity – existing clusters that migrate from OLM v0 to v1 retain fine-grained install-time configuration (env vars, volume mounts, tolerations, etc.) 

1. Security & reliability – OpenAPI-v3-based validation on the bundle side prevents malformed configurations from reaching the cluster 

1. Future extensibility – registry+v1 bundles already embed OpenAPI schemas in their CSV CRDs, making validation logic version-agnostic 

Scenarios

Acceptance Criteria

• API – ClusterExtension.spec.config accepts arbitrary JSON/YAML validated against the bundle-provided schema 

• Renderer – registry+v1 renderer merges config exactly like OLM v0’s Subscription path 

• Docs – Brief (Helm + registry+v1) and standalone RFC published in repo wiki

• CI – unit + e2e tests exercising happy-path and schema-fail cases run in GitHub Actions

• Release Technical Enablement – feature enablement guide updated in downstream docs

Dependencies

• Internal{}

• • OLM v1 API extension and CRD bump 

• • registry+v1 renderer enhancement
    (uses operators.operatorframework.io.bundle.mediatype.v1=registry+v1) 

• External{}

• • Bundle authors must ship OpenAPI schemas inside CSV CRDs 

Previous Work

• OLM v0 SubscriptionConfig design doc 

Open Questions

• Do we surface validation errors only in ClusterExtension.status or also via events?

• Should CLI (oc / kubectl) gain a helper flag that converts Helm values → spec.config?

• Minimum supported OCP version for the new field? (ties to CRD conversion strategy)

Done Checklist

• CI – pipelines green, tests merged

• Release Enablement –

• DEV – upstream code & tests:

• DEV Docs – API field documented:

• DEV – downstream build attached to advisory:

• QE – Polarion test plans & automated tests:

• DOC – downstream docs merged:

Key References

1. OLM v0 Subscription.config capabilities 

1. Helm custom values file pattern 

1. Kubernetes CRD OpenAPI validation mechanics 

1. Red Hat blog – Announcing OLM v1 

1. Red Hat Developer article – managing operators as ClusterExtensions 

1. registry+v1 bundle format labels 

1. Example OpenAPI schema inside CSV CRD