Skip to content

ESO-540/ESO-550: Adds concurrent flag, replicas, and experimentalOverrides to ExternalSecretsConfig - #2068

Open
siddhibhor-56 wants to merge 2 commits into
openshift:masterfrom
siddhibhor-56:ESO-533
Open

ESO-540/ESO-550: Adds concurrent flag, replicas, and experimentalOverrides to ExternalSecretsConfig#2068
siddhibhor-56 wants to merge 2 commits into
openshift:masterfrom
siddhibhor-56:ESO-533

Conversation

@siddhibhor-56

@siddhibhor-56 siddhibhor-56 commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

Summary

Updates the external-secrets-component-config enhancement proposal to add three new capabilities to the ExternalSecretsConfig API:

  • concurrent (spec.controllerConfig.concurrent): First-class field that translates to the upstream --concurrent=<N> CLI argument on the core controller, allowing administrators to tune reconcile parallelism for large-scale deployments (thousands of ExternalSecrets). CRD-validated min 1, max 100; defaults to 1 when unset. Not configurable via overrideEnv since it is a CLI arg, not an env var.
  • replicas (spec.controllerConfig.replicas): First-class field for the core controller Deployment replica count, enabling high availability. CRD-validated min 1, max 10; defaults to 1. Leader election (--enable-leader-election=true) is always enforced so only one replica actively reconciles.
  • experimentalOverrides (spec.controllerConfig.componentConfigs[].experimentalOverrides): Per-component runtime.RawExtension escape hatch that applies a strategic merge patch to the component Deployment.spec. Intended for scheduling fields (affinity, tolerations, nodeSelector, topologySpreadConstraints) until first-class fields exist. Patches targeting operator-owned nested lists (containers, initContainers, volumes, mounts) are rejected with a Degraded condition. Protected fields are re-asserted after any allowed patch.

Summary by CodeRabbit

  • New Features
    • Added operator-managed configuration for component metadata, deployment settings, and environment overrides.
    • Added core controller throughput and high-availability controls (concurrency and replicas).
    • Added trusted CA bundle support for core controller workloads.
    • Added an experimental escape hatch for advanced deployment tuning, with safeguards to protect operator-managed fields.
  • Documentation
    • Updated examples, workflow guidance/diagrams, test and upgrade instructions, and clarified trusted CA bundle and supported configuration limits.

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jul 27, 2026
@openshift-ci-robot

openshift-ci-robot commented Jul 27, 2026

Copy link
Copy Markdown

@siddhibhor-56: This pull request references ESO-533 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 epic to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

  • Documents the new per-component replicas field on DeploymentConfig (spec.controllerConfig.componentConfigs[].deploymentConfigs.replicas): default 1, validation as a positive integer (Minimum=1), and upgrade/downgrade behavior.
  • Documents leader-election implications when the External Secrets core controller runs with replicas > 1 (single active reconciler; standbys for failover).
  • Documents how experimentalOverrides (ESO-532) can be combined with replicas for HA scheduling via pod anti-affinity and topology spread constraints, with user-facing examples.

Test plan

  • Review API schema section for replicas (path, default, validation)
  • Confirm leader-election behavior for core controller is accurate vs operator implementation
  • Confirm experimentalOverrides HA examples align with ESO-532 direction
  • Enhancement linter / markdown CI passes

Made with Cursor

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
openshift-ci Bot requested review from TrilokGeer and mytreya-rh July 27, 2026 10:31
@siddhibhor-56
siddhibhor-56 marked this pull request as draft July 27, 2026 10:42
@openshift-ci openshift-ci Bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 27, 2026
@coderabbitai

coderabbitai Bot commented Jul 29, 2026

Copy link
Copy Markdown

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

Walkthrough

The proposal expands ExternalSecretsConfig with controller annotations, per-component overrides, trusted CA bundles, core-controller concurrency and replicas, experimental deployment patches, validation rules, examples, tests, and operational procedures.

Changes

External Secrets controller configuration

Layer / File(s) Summary
Configuration contract and reconciliation
enhancements/external-secrets-operator/external-secrets-component-config.md
ComponentConfig gains experimental deployment overrides, while ControllerConfig gains concurrency and replica fields with validation, Degraded handling, protected-field rules, and leader-election preservation.
Workflow and configuration examples
enhancements/external-secrets-operator/external-secrets-component-config.md
Workflow descriptions and YAML examples cover scaling fields, trusted CA configuration, and experimental deployment patches.
Validation and lifecycle coverage
enhancements/external-secrets-operator/external-secrets-component-config.md
Unit, integration, end-to-end, graduation, upgrade, downgrade, version-skew, and support procedures cover the expanded configuration and failure modes.
Proposal metadata and scope
enhancements/external-secrets-operator/external-secrets-component-config.md
Metadata, scope statements, interaction rules, risks, and mitigations are refreshed for the added capabilities.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Suggested labels: do-not-merge/work-in-progress, jira/valid-reference

Suggested reviewers: trilokgeer, mytreya-rh

🚥 Pre-merge checks | ✅ 15
✅ Passed checks (15 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the main change: adding concurrent, replicas, and experimentalOverrides to ExternalSecretsConfig.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names ✅ Passed Only a markdown proposal file changed; no Ginkgo test titles were added or modified, so the stability check is not applicable.
Test Structure And Quality ✅ Passed Only an enhancement-proposal markdown file changed; no Ginkgo test code was added or modified, so the test-structure check is not applicable.
Microshift Test Compatibility ✅ Passed Only an enhancement proposal markdown changed; no new Ginkgo/e2e tests or MicroShift-sensitive APIs were added, so the check is not applicable.
Single Node Openshift (Sno) Test Compatibility ✅ Passed Only a markdown enhancement proposal changed; no Ginkgo e2e tests or SNO-sensitive code were added.
Topology-Aware Scheduling Compatibility ✅ Passed Docs-only enhancement proposal; no operator/manifests changed, and the examples avoid control-plane node targeting or node-count-derived replicas.
Ote Binary Stdout Contract ✅ Passed PR changes only the enhancement-proposal markdown; no process-level code or stdout writes were introduced.
Ipv6 And Disconnected Network Test Compatibility ✅ Passed Only the enhancement proposal markdown changed; no Ginkgo e2e tests or network-facing code was added.
No-Weak-Crypto ✅ Passed No MD5/SHA1/DES/RC4/3DES/Blowfish/ECB or custom crypto code appears in the changed doc; only TLS/CA-bundle text is present.
Container-Privileges ✅ Passed Only a markdown proposal changed; no K8s manifests or privileged settings like hostNetwork/privileged/allowPrivilegeEscalation were added.
No-Sensitive-Data-In-Logs ✅ Passed No new logging code or sensitive log examples found; this is a proposal doc and keyword scans found only generic log/error references.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Comment @coderabbitai help to get the list of available commands.

@siddhibhor-56 siddhibhor-56 changed the title ESO-533: Document replicas field for ExternalSecretsConfig component config ESO-533: Adds Replicas, Concurrent and ExperimentalOverrides for ExternalSecretsConfig component config Jul 29, 2026
@siddhibhor-56 siddhibhor-56 changed the title ESO-533: Adds Replicas, Concurrent and ExperimentalOverrides for ExternalSecretsConfig component config ESO-533: Adds Replicas, Concurrent and ExperimentalOverrides feild for ExternalSecretsConfig component config Jul 29, 2026
@siddhibhor-56 siddhibhor-56 changed the title ESO-533: Adds Replicas, Concurrent and ExperimentalOverrides feild for ExternalSecretsConfig component config ESO-533: Adds Replicas, Concurrent and ExperimentalOverrides field for ExternalSecretsConfig component config Jul 29, 2026

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 14

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@enhancements/external-secrets-operator/external-secrets-component-config.md`:
- Line 22: Update the Jira metadata for ESO-533 so its target version is 5.0.0,
or document the intentional exception in the external-secrets component
configuration if the target version should remain unset.
- Around line 191-198: Update the workflow and support sections around the
visible forbidden-path references, including the diagram’s “Reject forbidden
nested lists” step, to consistently include containers, initContainers, volumes,
ephemeralContainers, volumeMounts, and volumeDevices. Preserve the existing
forbidden-path handling and ensure every mention uses this complete normative
list.
- Around line 105-115: Update the trustedCABundle mount decision in the External
Secrets controller reconciliation to skip the user CA volume only when the
referenced ConfigMap is confirmed to be the known CNO/proxy-managed bundle
already mounted in the controller pod. Do not skip mounting solely because the
ConfigMap has the injection label; mount arbitrary labeled references normally,
while preserving existing optional and invalid-PEM handling.
- Around line 471-479: Update the required podAntiAffinity selectors in both
examples around the affinity configuration to use the exact labels emitted on
the operator-rendered core-controller pods instead of hard-coded
app.kubernetes.io/name: external-secrets. Verify the selector matches those pods
and add or update the relevant test to enforce that match.
- Around line 140-152: The experimentalOverrides validation described in the
component configuration must enforce an explicit allowlist rather than only
rejecting forbidden paths. Update the override validation or application logic
associated with the external secrets component to permit only the documented
scheduling paths under Deployment.spec, such as template.spec.affinity,
tolerations, nodeSelector, and topologySpreadConstraints, and reject every other
path—including currently unlisted fields—by setting Degraded and skipping the
patch.
- Around line 680-685: Clarify the Downgrade section to document the supported
downgrade procedure: distinguish operator-image rollback from the active CRD
schema transition, specify the required CRD/version change, and describe backup
and reapply expectations when fields are rejected or pruned. State the exact
supported downgrade path before describing the resulting behavior or
availability risks.
- Around line 696-700: The upgrade discussion must not describe OLM bundle
upgrades as atomic or imply there is no version skew. Update the section around
the ExternalSecretsConfig fields to document the supported upgrade order,
acknowledge that operator and operand Deployments may temporarily run different
revisions, and specify the behavior when ExternalSecretsConfig is changed before
the new operator finishes rolling out.

In `@enhancements/installer/gcp-sovereign-cloud.md`:
- Around line 320-362: Update validateGCPServices to probe all six required
services listed in requiredServices, rather than validating only Compute. Add
bounded API-access checks for Cloud Resource Manager, DNS, IAM, IAM Credentials,
Service Usage, and Compute; classify any non-required capabilities separately as
optional, and return a clear service-specific error immediately when a required
probe is unavailable so provisioning does not begin.
- Around line 654-692: The GCD installer documentation does not specify
enforceable defaults or preflight checks for unsupported resources. Update the
installer configuration and provisioning flow to use supported C3/M3/A3 Edge
machine types and Hyperdisk Balanced disks, and validate load balancers, DNS
zones, and SSL certificates before infrastructure creation, failing fast with
actionable errors for unsupported global, public, or managed options.
- Around line 340-352: Make the snippets around validateGCPServices and the
related resource-manager example self-contained: define or pass projectID
explicitly, expose client.projectID if it is intended, and provide the
GetResourceManagerService helper before use. If these examples are intentionally
illustrative, label them clearly as pseudocode instead of leaving undefined
references.
- Around line 373-400: Update validateRegion to follow the nextPageToken
returned by computeSvc.Regions.List(client.projectID).Do(), fetching and
scanning every regions page before concluding the region is unavailable.
Accumulate region names from all pages so both validation and the
available-regions error message include the complete result set.
- Around line 62-69: Unify the GCP configuration contract across
enhancements/installer/gcp-sovereign-cloud.md:62-69 by defining universeDomain
as the canonical source, its precedence over cloudEnvironment and other inputs,
defaults, and mismatch behavior; update
enhancements/installer/gcp-sovereign-cloud.md:591-603 so the GCD example uses
only documented install-config fields; and update
enhancements/installer/gcp-sovereign-cloud.md:791-805 so version-skew handling
derives from the same source of truth used for component discovery.
- Around line 535-547: Update the credential-loading flow before
compute.NewService and the other GCP client constructors to use the typed
authentication loader instead of deprecated option.WithCredentialsJSON. Validate
the parsed credential type and universe/endpoint fields, rejecting unexpected
values before creating any client, while preserving automatic universe-domain
endpoint and authentication selection for supported credentials.
- Around line 218-240: Align the authentication guidance in
enhancements/installer/gcp-sovereign-cloud.md lines 218-240 and 471-508 to one
consistent current Go client-library contract: update the examples to use
option.WithAuthCredentialsJSON with option.ServiceAccount and credentials JSON,
and describe self-signed JWT as being derived by the SDK from the
service-account key rather than embedded in the JSON. Ensure both sections
consistently explain whether WithUniverseDomain is required, without mixing
incompatible authentication paths.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: dce47c73-3036-4784-bc38-611c4f38ee6c

📥 Commits

Reviewing files that changed from the base of the PR and between f806339 and 0c907cd.

📒 Files selected for processing (2)
  • enhancements/external-secrets-operator/external-secrets-component-config.md
  • enhancements/installer/gcp-sovereign-cloud.md

Comment thread enhancements/external-secrets-operator/external-secrets-component-config.md Outdated
Comment on lines +105 to +115
`**ConfigMap` with the CNO injection label:** If the `ConfigMap` referenced by `trustedCABundle` is labeled with `config.openshift.io/inject-trusted-cabundle: "true"`, operator **skips** mounting that reference for `trustedCABundle`.

**Interaction with `overrideEnv`:** The operator owns `**SSL_CERT_DIR`** (and, when applicable, `**SSL_CERT_FILE**`) on the **External Secrets core controller** for proxy/CNO trust and for `**trustedCABundle`** injection. `**overrideEnv**` therefore **must not** set `**SSL_CERT_DIR`** or `**SSL_CERT_FILE**` on **any** operand component: the `**ExternalSecretsConfig`** CRD extends the existing `**overrideEnv**` CEL rule so the API server **rejects** those names up front (same pattern as reserved prefixes such as `KUBERNETES_`). No runtime “ignore vs reject” choice is required for a valid CR. Concurrency is **not** configurable via `overrideEnv`; use the first-class `**concurrent`** field (the operator builds container `args`, not an env var, for `--concurrent`).


| Situation | Expected behaviour |
| ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `optional: false` (default) and missing `ConfigMap` or key | **Degraded**; do not patch the controller `Deployment` until valid. |
| `optional: true` and missing `ConfigMap` or key | Skip user bundle; no error for the missing reference alone. |
| Present key with **invalid PEM** | **Degraded** regardless of `optional`. |
| Referenced `ConfigMap` has `**config.openshift.io/inject-trusted-cabundle: "true"`** | A `ConfigMap` is already created, when proxy is configured, and its contents are mounted at `/etc/pki/tls/certs` path. Mounting it again under `/etc/pki/tls/user-certs` would be a duplicate. The operator **skips** the trustedCABundle volume mount. |

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

Do not skip the user CA mount based only on the injection label.

A config.openshift.io/inject-trusted-cabundle: "true" label does not by itself prove that this referenced ConfigMap is the CNO-managed bundle already mounted in the controller pod. Skipping the mount for an arbitrary labeled ConfigMap can leave the controller without the requested trust roots. Restrict this optimization to the known CNO/proxy-mounted bundle and otherwise mount the referenced ConfigMap.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@enhancements/external-secrets-operator/external-secrets-component-config.md`
around lines 105 - 115, Update the trustedCABundle mount decision in the
External Secrets controller reconciliation to skip the user CA volume only when
the referenced ConfigMap is confirmed to be the known CNO/proxy-managed bundle
already mounted in the controller pod. Do not skip mounting solely because the
ConfigMap has the injection label; mount arbitrary labeled references normally,
while preserving existing optional and invalid-PEM handling.

Comment thread enhancements/external-secrets-operator/external-secrets-component-config.md Outdated
Comment on lines +471 to +479
template:
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app.kubernetes.io/name: external-secrets
topologyKey: kubernetes.io/hostname

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Use labels guaranteed to match the operand pods.

The required anti-affinity examples hard-code app.kubernetes.io/name: external-secrets. If the operator-rendered pod labels differ, the selector matches nothing and replicas can co-locate, defeating the HA example. Use the exact emitted labels and test that the selector matches the core-controller pods.

Also applies to: 537-546

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@enhancements/external-secrets-operator/external-secrets-component-config.md`
around lines 471 - 479, Update the required podAntiAffinity selectors in both
examples around the affinity configuration to use the exact labels emitted on
the operator-rendered core-controller pods instead of hard-coded
app.kubernetes.io/name: external-secrets. Verify the selector matches those pods
and add or update the relevant test to enforce that match.

Comment thread enhancements/installer/gcp-sovereign-cloud.md
Comment thread enhancements/installer/gcp-sovereign-cloud.md
Comment thread enhancements/installer/gcp-sovereign-cloud.md
Comment thread enhancements/installer/gcp-sovereign-cloud.md
Comment thread enhancements/installer/gcp-sovereign-cloud.md
@openshift-ci openshift-ci Bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 29, 2026
@openshift-ci

openshift-ci Bot commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

[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 mytreya-rh 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:

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

@openshift-ci openshift-ci Bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jul 29, 2026

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
enhancements/external-secrets-operator/external-secrets-component-config.md (1)

291-291: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Use = for these Kubebuilder validation markers.
Enum:=, Minimum:=, Maximum:=, MinItems:=, MinLength:=, MaxLength:=, and Pattern:= should all be = here, otherwise the generated CRD will miss the intended constraints.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@enhancements/external-secrets-operator/external-secrets-component-config.md`
at line 291, Update the Kubebuilder validation marker near the component enum to
use the supported equals syntax, changing the Enum marker from `Enum:=` to
`Enum=` so the generated CRD preserves the constraint.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@enhancements/external-secrets-operator/external-secrets-component-config.md`:
- Line 291: Update the Kubebuilder validation marker near the component enum to
use the supported equals syntax, changing the Enum marker from `Enum:=` to
`Enum=` so the generated CRD preserves the constraint.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 48b40099-9e37-4461-830e-e17b62e43ede

📥 Commits

Reviewing files that changed from the base of the PR and between bce4fcd and 37de840.

📒 Files selected for processing (1)
  • enhancements/external-secrets-operator/external-secrets-component-config.md

@siddhibhor-56 siddhibhor-56 changed the title ESO-533: Adds Replicas, Concurrent and ExperimentalOverrides field for ExternalSecretsConfig component config ESO-532/ESO-533: Add concurrent, replicas, and experimentalOverrides to ExternalSecretsConfig Jul 29, 2026
@siddhibhor-56
siddhibhor-56 marked this pull request as ready for review July 29, 2026 18:44
@openshift-ci openshift-ci Bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jul 29, 2026

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@enhancements/external-secrets-operator/external-secrets-component-config.md`:
- Around line 75-82: Update the Non-Goals wording around component-level
scheduling configuration to clarify that affinity, anti-affinity, tolerations,
and node selectors are excluded only as first-class API fields. Explicitly state
that these settings remain available through the documented
experimentalOverrides escape hatch, while preserving the existing restrictions
on operator-owned containers, initContainers, and volumes.
- Around line 635-637: Update the test plan around experimentalOverrides to
separate rejected protected-field patches from successful allowed scheduling
patches. Verify patches targeting image, --enable-leader-election, concurrent,
replicas, containers, initContainers, or volumes produce Degraded and leave the
Deployment unchanged; separately verify allowed scheduling patches succeed while
preserving the operator baseline.
- Around line 135-150: Remove the statement that webhook, cert-controller, and
Bitwarden replica counts can be configured through experimentalOverrides, since
the forbidden-path rules reject replicas patches. Update the surrounding
experimentalOverrides documentation to state that non-core replica counts are
unsupported while preserving the existing replicas prohibition.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 3acfa3ce-91fb-4fab-8f7a-9aa10d486786

📥 Commits

Reviewing files that changed from the base of the PR and between 37de840 and f959be3.

📒 Files selected for processing (1)
  • enhancements/external-secrets-operator/external-secrets-component-config.md

Comment thread enhancements/external-secrets-operator/external-secrets-component-config.md Outdated
Comment thread enhancements/external-secrets-operator/external-secrets-component-config.md Outdated
@siddhibhor-56 siddhibhor-56 changed the title ESO-532/ESO-533: Add concurrent, replicas, and experimentalOverrides to ExternalSecretsConfig ESO-540/ESO-550: Add concurrent, replicas, and experimentalOverrides to ExternalSecretsConfig Jul 30, 2026
@openshift-ci-robot

openshift-ci-robot commented Jul 30, 2026

Copy link
Copy Markdown

@siddhibhor-56: This pull request references ESO-550 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 story to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

Updates the external-secrets-component-config enhancement proposal to add three new capabilities to the ExternalSecretsConfig API:

  • concurrent (spec.controllerConfig.concurrent): First-class field that translates to the upstream --concurrent=<N> CLI argument on the core controller, allowing administrators to tune reconcile parallelism for large-scale deployments (thousands of ExternalSecrets). CRD-validated min 1, max 100; defaults to 1 when unset. Not configurable via overrideEnv since it is a CLI arg, not an env var.
  • replicas (spec.controllerConfig.replicas): First-class field for the core controller Deployment replica count, enabling high availability. CRD-validated min 1, max 10; defaults to 1. Leader election (--enable-leader-election=true) is always enforced so only one replica actively reconciles.
  • experimentalOverrides (spec.controllerConfig.componentConfigs[].experimentalOverrides): Per-component runtime.RawExtension escape hatch that applies a strategic merge patch to the component Deployment.spec. Intended for scheduling fields (affinity, tolerations, nodeSelector, topologySpreadConstraints) until first-class fields exist. Patches targeting operator-owned nested lists (containers, initContainers, volumes, mounts) are rejected with a Degraded condition. Protected fields are re-asserted after any allowed patch.

Summary by CodeRabbit

  • New Features

  • Added operator-managed configuration for component metadata, deployment settings, and environment overrides.

  • Added core controller concurrency and replica controls.

  • Added trusted CA bundle support for core controller workloads.

  • Added experimental deployment overrides with validation and protection for operator-managed fields.

  • Documentation

  • Updated configuration examples, workflows, diagrams, testing guidance, and upgrade procedures.

  • Documented trusted CA bundle behavior and supported configuration limits.

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.

@siddhibhor-56 siddhibhor-56 changed the title ESO-540/ESO-550: Add concurrent, replicas, and experimentalOverrides to ExternalSecretsConfig ESO-540/ESO-550: Adds concurrent flag, replicas, and experimentalOverrides to ExternalSecretsConfig Jul 30, 2026

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
enhancements/external-secrets-operator/external-secrets-component-config.md (1)

13-22: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Set the target version for ESO-550.

OpenShift CI confirms that ESO-550 is valid but has no target version, while this branch expects 5.0.0. Update the Jira metadata or document the intentional exception before merge.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@enhancements/external-secrets-operator/external-secrets-component-config.md`
around lines 13 - 22, Update the Jira metadata associated with ESO-550 in the
tracking-link section to set its target version to 5.0.0. If that metadata
cannot be changed, document the intentional target-version exception in this
component configuration instead.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@enhancements/external-secrets-operator/external-secrets-component-config.md`:
- Around line 629-635: The test plan for experimentalOverrides must explicitly
verify that forbidden patches both set the component to Degraded and leave the
Deployment unchanged. Add parameterized rejection cases covering image,
args/command, trust-related environment variables, concurrent, replicas,
ephemeralContainers, volumeMounts, and volumeDevices, while keeping successful
scheduling-only patches in a separate test group.
- Line 188: Update the forbidden nested-list guidance in the workflow and
support references, including the diagram at the visible Op->>Op step and the
corresponding sections, to consistently name containers, initContainers,
ephemeralContainers, volumes, volumeMounts, and volumeDevices. Replace
abbreviated “mounts” wording with the exact normative field names while
preserving the existing validation guidance.
- Around line 139-153: Update the override contract documentation to define an
explicit allowlist: only the listed scheduling and placement paths may be
patched, and every other Deployment.spec path must be rejected. Resolve the
non-core replicas inconsistency by either removing its support or documenting it
as an explicit validated exception, ensuring the stated scaling contract and
validation behavior agree.

---

Outside diff comments:
In `@enhancements/external-secrets-operator/external-secrets-component-config.md`:
- Around line 13-22: Update the Jira metadata associated with ESO-550 in the
tracking-link section to set its target version to 5.0.0. If that metadata
cannot be changed, document the intentional target-version exception in this
component configuration instead.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 87fadc52-3755-4962-9a08-8e27f779755c

📥 Commits

Reviewing files that changed from the base of the PR and between f959be3 and ba97cac.

📒 Files selected for processing (1)
  • enhancements/external-secrets-operator/external-secrets-component-config.md

Comment on lines +139 to +153
- **Allowed paths** (scheduling / placement fields), for example:
- `template.spec.affinity`
- `template.spec.tolerations`
- `template.spec.nodeSelector`
- `template.spec.topologySpreadConstraints`
- **Forbidden paths** — the operator rejects patches targeting these and sets **Degraded**:
- `template.spec.containers`, `initContainers`, `ephemeralContainers`
- `template.spec.volumes`
- `template.spec.containers[*].volumeMounts` / `volumeDevices` (same for init containers)
- Operator-owned scalars that conflict with dedicated fields on the **core controller**: `replicas` (use the dedicated field instead), container `image`, `args` / `command`, `SSL_CERT_DIR` / `SSL_CERT_FILE`. For non-core components (webhook, cert-controller, Bitwarden), `replicas` is allowed via `experimentalOverrides` since no dedicated field exists.
- **Apply order** per component Deployment:
1. Start from the operator baseline (bindata).
2. Apply operator-managed settings (image, args, trusted CA mounts, labels, annotations, `revisionHistoryLimit`, `overrideEnv`, `concurrent`, `replicas`).
3. Check `experimentalOverrides` against forbidden paths; if violated, set **Degraded** and skip the patch.
4. Strategic-merge-patch `Deployment.spec` with the allowed overrides.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift

Make the override contract an explicit allowlist.

“Allowed paths … for example” combined with forbidden-path checks leaves every unlisted Deployment.spec field implicitly patchable. That can expose selectors, service accounts, networking, security settings, and rollout behavior. Also resolve whether non-core replicas are truly supported; that exception conflicts with the scheduling-only scope and the core-only scaling contract.

Document that every path outside the explicit allowlist is rejected, and either remove non-core replica support or add it as an explicit, validated, tested exception.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@enhancements/external-secrets-operator/external-secrets-component-config.md`
around lines 139 - 153, Update the override contract documentation to define an
explicit allowlist: only the listed scheduling and placement paths may be
patched, and every other Deployment.spec path must be rejected. Resolve the
non-core replicas inconsistency by either removing its support or documenting it
as an explicit validated exception, ensuring the stated scaling contract and
validation behavior agree.


rect rgb(120, 60, 140)
Note over Op,Deps: 2b — experimentalOverrides (per component)
Op->>Op: Reject forbidden nested lists<br/>(containers / initContainers / volumes / mounts)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Keep forbidden-path guidance complete everywhere.

The normative contract includes ephemeralContainers, volumeMounts, and volumeDevices, but these workflow and support references only mention abbreviated subsets such as containers, initContainers, volumes, and “mounts.” Use the complete list consistently so remediation guidance matches validation behavior.

Also applies to: 254-256, 749-749

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@enhancements/external-secrets-operator/external-secrets-component-config.md`
at line 188, Update the forbidden nested-list guidance in the workflow and
support references, including the diagram at the visible Op->>Op step and the
corresponding sections, to consistently name containers, initContainers,
ephemeralContainers, volumes, volumeMounts, and volumeDevices. Replace
abbreviated “mounts” wording with the exact normative field names while
preserving the existing validation guidance.

Comment on lines +629 to +635
14. Test that `concurrent` renders `--concurrent=<N>` on the core controller; unset defaults to `1`.
15. Test that `replicas` sets `Deployment.spec.replicas` on the core controller; unset defaults to `1`.
16. Test that valid `experimentalOverrides` are merged into `Deployment.spec` for allowed paths.
17. Test that invalid `experimentalOverrides` sets **Degraded**.
18. Test that protected fields (`image`, `--enable-leader-election`, `concurrent`, `replicas`) are not overridden by `experimentalOverrides`.
19. Test that `experimentalOverrides` targeting `containers`, `initContainers`, or `volumes` is rejected with **Degraded**.
20. Test that operator-owned fields are restored after an allowed patch is applied.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Test the Degraded/no-change contract explicitly.

The protected-field case only checks that values are not overridden, but forbidden patches must be rejected with Degraded and leave the Deployment unchanged. Add parameterized cases for image, args/command, trust-related environment variables, concurrent, replicas, ephemeralContainers, volumeMounts, and volumeDevices; keep successful allowed scheduling patches as a separate test group.

🧰 Tools
🪛 LanguageTool

[style] ~631-~631: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...troller; unset defaults to 1. 16. Test that valid experimentalOverrides are ...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~632-~632: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...oyment.specfor allowed paths. 17. Test that invalidexperimentalOverrides` se...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~633-~633: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...alOverrides sets **Degraded**. 18. Test that protected fields (image, --enab...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~634-~634: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...den by experimentalOverrides. 19. Test that experimentalOverrides targeting ...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)


[style] ~635-~635: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... is rejected with Degraded. 20. Test that operator-owned fields are restored...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@enhancements/external-secrets-operator/external-secrets-component-config.md`
around lines 629 - 635, The test plan for experimentalOverrides must explicitly
verify that forbidden patches both set the component to Degraded and leave the
Deployment unchanged. Add parameterized rejection cases covering image,
args/command, trust-related environment variables, concurrent, replicas,
ephemeralContainers, volumeMounts, and volumeDevices, while keeping successful
scheduling-only patches in a separate test group.

@openshift-ci

openshift-ci Bot commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

@siddhibhor-56: all tests passed!

Full PR test history. Your PR dashboard.

Details

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. I understand the commands that are listed here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

jira/valid-reference Indicates that this PR references a valid Jira ticket of any type.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants