OPRUN-4099: OLMv1 Deployment Configuration API

[oceanc80]

Enhancement extending OLMv1's ClusterExtension API to support deployment configuration in order to provide feature parity with OLMv0's SubscriptionConfig.

[openshift-ci-robot]

@oceanc80: This pull request references OPRUN-4099 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Enhancement extending OLMv1's ClusterExtension API to support deployment configuration in order to provide feature parity with OLMv0's SubscriptionConfig.

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[perdasilva]

I wonder what the story for the Selector is. I wonder if its to handle changes in the pod label selector in the operator's controller deployment between versions (the label selector in the deployment spec is immutable). This configuration could provide upgrade continuity across this type of breaking change.

[oceanc80]

I could also see it being used for blue/green deployments or other similar deployment strategies.

[kuiwang02]

@oceanc80 I know the PR is in WIP, and I also am not sure if the following comment is the scope of this EP.

If the following comment is not the scope of this EP or it is not correct time to raise the comments, you could ignore the following the comment:

---

The deploymentConfig API design looks well thought out. I noticed that the proposal currently focuses on initial installation scenarios, and I was wondering if you could clarify the behavior for runtime configuration updates, which I expect will be a common operational workflow.

Question 1: Modifying Existing deploymentConfig Values

Scenario: After creating a ClusterExtension with deploymentConfig, a user wants to update some values (e.g., changing memory limits from 256Mi to 512Mi, or adding a new nodeSelector).

Could you clarify:

1. Will users be able to modify spec.config.inline.deploymentConfig values after ClusterExtension creation?
2. If supported, will the changes automatically reconcile and apply to the existing Deployment?
3. Which configuration field changes will trigger a pod rolling update?
4. Are there any fields that don't support runtime updates?

Example:

  # Initial configuration
  deploymentConfig:
    resources:
      limits:
        memory: "256Mi"

  # User updates to:
  deploymentConfig:
    resources:
      limits:
        memory: "512Mi"      # ← modified
    nodeSelector:            # ← added
      infrastructure: "dedicated"

Question 2: Adding deploymentConfig After Creation

Scenario: A user creates a ClusterExtension without defining deploymentConfig initially, then later wants to add deployment configuration.

Could you clarify:

1. Is it supported to add deploymentConfig to an existing ClusterExtension that was created without it?
2. If supported, will the changes automatically reconcile and apply to the existing Deployment?
3. Which new configuration field will trigger a pod rolling update?
4. Are there any fields that don't support runtime added?
5. Similarly, what happens if a user removes deploymentConfig entirely?

Example:

  # Initial creation (no deploymentConfig)
  apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: my-operator
  spec:
    source:
      sourceType: Catalog
      catalog:
        packageName: my-operator
    # Note: no config.inline.deploymentConfig

  ---

  # Later, user adds deploymentConfig
  spec:
    config:
      inline:
        deploymentConfig:    # ← newly added
          nodeSelector:
            infrastructure: "dedicated"

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign jmguzik for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[perdasilva]

@kuiwang02 let me try to reply to your questions

Question 1: Modifying Existing deploymentConfig Values

1. Will users be able to modify spec.config.inline.deploymentConfig values after ClusterExtension creation?

From the perspective of OLMv1, bundle configuration is opaque. It will take user input, validated it against the configuration schema provided by the bundle, and apply it to generate the final manifests. So, any configuration can
be changed at runtime. This does mean that some user configurations might generate manifests that cannot be applied, or could lead to unintended or bad consequences. If there are errors, the extension will be in a broken state until the configuration is fixed.

2. If supported, will the changes automatically reconcile and apply to the existing Deployment?

Yes. The Deployment will be regenerated with the new values and applied to the cluster.

3. Which configuration field changes will trigger a pod rolling update?

I'd say so, yes. Any changes to the pod template should trigger a new replicaset and the deployment will transition towards that.

4. Are there any fields that don't support runtime updates?

This is a good question. I know there are fields in the Deployment spec that are immutable (e.g. the label selector). That the only one I can think of. I think the configuration options under the deployment config are mutable.

Question 2: Adding deploymentConfig After Creation

1. Is it supported to add deploymentConfig to an existing ClusterExtension that was created without it?

Yes. For the same reasons in Q1.1

2. If supported, will the changes automatically reconcile and apply to the existing Deployment?

Yes.

3. Which new configuration field will trigger a pod rolling update?

Yes.

4. Are there any fields that don't support runtime added?

I don't think so.

5. Similarly, what happens if a user removes deploymentConfig entirely?

Then we are back to the Deployment spec defined in the bundle by the author.

The mental model here is really no different than:

1. Create a Deployment
2. Modify the deployment

AFAIK only the pod label selector is immutable once set.

[kuiwang02]

immutable

@perdasilva Thanks for your great reply. I got it.