OPRUN-4099: OLMv1 Deployment Configuration API#1915
OPRUN-4099: OLMv1 Deployment Configuration API#1915openshift-merge-bot[bot] merged 15 commits intoopenshift:masterfrom
Conversation
openshift-ci-robot
added
the
jira/valid-reference
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
|
@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. DetailsIn response to this:
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. |
|
Skipping CI for Draft Pull Request. |
| - As a cluster extension admin, I want to attach custom storage volumes to operator pods, so that I can provide persistent storage or configuration files to operators. | ||
| - As a cluster extension admin, I want to configure pod affinity rules for operator deployments, so that I can control how operator pods are distributed across cluster nodes. | ||
| - As a cluster extension admin, I want to add custom annotations to operator deployments, so that I can integrate with monitoring and observability tools. | ||
|
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I could also see it being used for blue/green deployments or other similar deployment strategies.
There was a problem hiding this comment.
The selector of a deployment is immutable, iirc. I dove into the history of this field, and it looks like it was basically there from the beginning with no real explanation that I could find, and it has never been honored as far as I can tell.
Chalk it up to how fast and loose the early days of OLM were.
|
@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:
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:
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" |
static at runtime, dynamic at build time
|
@kuiwang02 let me try to reply to your questions
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
Yes. The Deployment will be regenerated with the new values and applied to the cluster.
I'd say so, yes. Any changes to the pod template should trigger a new replicaset and the deployment will transition towards that.
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.
Yes. For the same reasons in Q1.1
Yes.
Yes.
I don't think so.
Then we are back to the Deployment spec defined in the bundle by the author. The mental model here is really no different than:
AFAIK only the pod label selector is immutable once set. |
@perdasilva Thanks for your great reply. I got it. |
openshift-ci
Bot
removed
the
do-not-merge/work-in-progress
|
@JoelSpeed PTAL, thanks! |
| } | ||
| ``` | ||
|
|
||
| The `Selector` field in the `SubscriptionConfig` is present but is not ever extracted or used by OLMv0. OLMv1 will maintain this behavior so the field will be accepted but ignored. |
There was a problem hiding this comment.
Accepting but ignoring a field is bad practice. Why not create a new type for the deployment config? It doesn't look like it'll be particularly complex to implement
There was a problem hiding this comment.
Same answer as above:
we had this discussion upstream where I'd proposed a new, completely separate structure for v1, but it was vetoed in favor of keeping v0 and v1 in sync.
It was discussed that reusing the v0 structure would mean carrying over debts, but the cost of it was assessed to be acceptable for long term maintainability
There was a problem hiding this comment.
I agree with @JoelSpeed 's point here. Even if we re-use the type, we are also in control of the schema generation for that type, right? So at a minimum we could specifically exclude that field from the generated schema.
There was a problem hiding this comment.
Big +1 to excluding this field from the schema downstream if it's not going to be supported
There was a problem hiding this comment.
Looks like there's some confusion here: we are NOT exposing the field in the schema, even though it's being carried over because of the usage of v1alpha1.SubscriptionConfig.
Wrote a test to make that more explicit: operator-framework/operator-controller#2525
Also @oceanc80 fyi oceanc80#2
| ## Open Questions / Considerations | ||
|
|
||
| ### Track changes to underlying kubernetes corev1 structures? | ||
| SubscriptionConfig uses many kubernetes corev1 structures from the standard kube lib. This means that the OLMv0 Subscription API would track changes to those structures (e.g. if a new Volume type is added to the API etc.). We need to think about whether we want the same behavior here, and if so how we'd like to implement it. E.g. we could have some process downloading and mining the openapi specs for the given kube lib version we have in go.mod, and having make verify fail when that changes. We'd want to think about how we'd handle any CEL expressions in those corev1 structures when doing the validation (and whether we want to handle them?). |
There was a problem hiding this comment.
Are you doing any processing of these fields, or just setting them directly on the deployment that you're rendering and applying? If you aren't processing them and are just passing them through, then this is probably fine
There was a problem hiding this comment.
Just passing them through without any processing. See https://docs.google.com/document/d/18O4qBvu5I4WIJgo5KU1opyUKcrfgk64xsI3tyXxmVEU/edit?tab=t.0#bookmark=kix.1y89z5sf1akf for more details.
add selector field clarification
|
@JoelSpeed can we move this along? Our downstreaming efforts are currently blocked by this EP's merging (the feature is planned for TPNU for this release) |
|
None of my comments here are blocking, though I do recommend you double check on #1915 (comment) /override ci/prow/markdownlint New sections were added to the template after you started this /assign @joelanford Joe is listed as your approver |
|
@JoelSpeed: Overrode contexts on behalf of JoelSpeed: ci/prow/markdownlint DetailsIn response to this:
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. |
| 1. OLM Team (primary) | ||
| 2. Layered Product Team |
There was a problem hiding this comment.
Flip this around. Layered product teams are better positioned to answer questions about issues with their specific operator configurations and interplay with their CSV's stated defaults. I would expect:
- Customer escalates to layered product team
- If LP team can't diagnose, LP team escalates to OLM team.
flip responsible team
|
/test markdownlint |
This should allow this to pass markdownlint Signed-off-by: Todd Short <todd.short@me.com>
Add missing headers
| - everettraven | ||
| creation-date: 2025-12-30 | ||
| last-updated: 2025-12-30 | ||
| tracking-link: |
There was a problem hiding this comment.
Add status: provisional (or implementable?). Not sure which is appropriate for "ready for tech preview implementation.
| 1. Layered Product Teams (primary) | ||
| 2. OLM Team | ||
|
|
||
| ## Support Procedures |
There was a problem hiding this comment.
The template lists this as a section without the "optional" label, and there are some examples of the kinds of things that are useful to document here. Not necessary for TechPreview, but something we'll need to populate before promoting to GA.
| ## Upgrade / Downgrade Strategy | ||
|
|
||
| ### Upgrade | ||
|
|
||
| ### Downgrade | ||
|
|
||
| ## Version Skew Strategy |
There was a problem hiding this comment.
We need to populate these sections. Descriptions are present in the template.
- https://github.com/openshift/enhancements/blob/master/guidelines/enhancement_template.md#upgrade--downgrade-strategy
- https://github.com/openshift/enhancements/blob/master/guidelines/enhancement_template.md#version-skew-strategy
Not a merge blocker, but something that needs to be done prior to GA promotion.
| ### Removing a deprecated feature | ||
|
|
There was a problem hiding this comment.
Non-blocking: Remove this section title, since this EP is not about removal of a deprecated feature.
There was a problem hiding this comment.
It's required per the markdownlint CI.
| api-approvers: | ||
| - everettraven | ||
| creation-date: 2025-12-30 | ||
| last-updated: 2025-12-30 |
|
|
||
| Example inline configuration structure: | ||
|
|
||
| ```yaml |
There was a problem hiding this comment.
Nit: yaml code block, but JSON content. Align these?
Signed-off-by: Todd Short <todd.short@me.com>
Address latest comments
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: joelanford The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
Bot
added
the
approved
|
@JoelSpeed How does this look now? |
|
or @everettraven ? |
|
/lgtm |
|
@oceanc80: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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. I understand the commands that are listed here. |
8 participants
Enhancement extending OLMv1's ClusterExtension API to support deployment configuration in order to provide feature parity with OLMv0's SubscriptionConfig.