wire csi-lib GateBackoffConfig as --gate-backoff-* flags and Helm values

[patyogesh20]

Why

csi-lib's renewal loop used a single backoff (RenewalBackoffConfig, default 30s base / 5min cap) for both genuine issuance failures (signer down, apiserver errors, denials) and ReadyToRequestFunc returning false. With --pod-readiness-gate configured, that cadence is wrong for the gate-pending case: the underlying condition
(CNI assigning a pod IP, a controller flipping a pod condition) typically resolves in seconds, but the driver was sleeping for 30+ seconds between checks. csi-lib#235 separated the two backoffs by adding GateBackoffConfig. This PR exposes that option to csi-driver operators.

What this PR changes

• Four new CLI flags on cert-manager-csi-driver, mirroring wait.Backoff fields:
  • --gate-backoff-duration (default 1s)
  • --gate-backoff-factor (default 2.0)
  • --gate-backoff-jitter (default 0.5)
  • --gate-backoff-cap (default 10s)
• Wiring in cmd/app/app.go: mgrOpts.GateBackoffConfig is set from these flags

Backwards compatibility

• Deployments without --pod-readiness-gate: no behaviour change. mgrOpts.GateBackoffConfig is left nil, csi-lib uses its own defaults if
• Deployments with --pod-readiness-gate: the gate-pending wait window drops from csi-lib's renewal-backoff cadence (~30s) to the gate-backoff cadence (~1s typical), which is the entire point of the change.
• Existing RenewalBackoffConfig behaviour is unchanged. Issuance errors still use the signer-protective backoff.

Dependencies

• go.mod currently points at a pseudo-version of csi-lib (v0.10.1-0.20260624100922-4eeba3e02d4e) covering the merge of csi-lib#235. Before merging this PR, the dependency should be bumped to a tagged csi-lib release containing [CI] Merge self-upgrade into main #235 — happy to amend once a release is cut.

[cert-manager-prow]

[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 maelvls 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

[cert-manager-prow]

Hi @patyogesh20. Thanks for your PR.

I'm waiting for a cert-manager member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[cert-manager-prow]

@patyogesh20: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

Details

In response to this:

/ok-to-test

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.

[SgtCoDFish]

Few minor things, hopefully shouldn't take long. Thank you for this!

[SgtCoDFish]

suggestion (non-blocking): We don't validate any of the values from the options at all, which could maybe bite users in the future. I don't think we need to go super crazy validating them (these are fairly advanced options) but maybe we could do some basic checks? Your call.

[patyogesh20]

I see your point and agree that, the implications of having these values mis-configured are not simple like failed Vs succeeded. Added validateGateBackoff(opts) helper. Validation checks are simple with the failure mode is clear startup error. Error message is to signal how the values should be chosen rather than what.

1. Duration > 0
2. Factor >= 1
3. Jitter in [0,1]
4. Cap >= Duration.

[SgtCoDFish]

Hmm, I'm not sure about Cap >= Duration - we force Duration > 0 which implies that Cap must be > 0.

But setting Cap to zero would disable the cap, which is a valid thing to want, right?

Put another way, I think we should check Cap == 0 || Cap >= Duration, no?

[patyogesh20]

This is addressed now with following check in validateGateBackoff() func in cmd/app/app.go

if opts.GateBackoffCap != 0 && opts.GateBackoffCap < opts.GateBackoffDuration {
		return fmt.Errorf("--gate-backoff-cap (%s) must be 0 (uncapped) or >= --gate-backoff-duration (%s)", opts.GateBackoffCap, opts.GateBackoffDuration)
	}

[patyogesh20]

Few minor things, hopefully shouldn't take long. Thank you for this!

thank you for the review and spotting the incosistency. I have addressed your comments.

[SgtCoDFish]

/ok-to-test

[SgtCoDFish]

Couple more bits - please feel free to ignore the AI suggestion as it's a small improvement but not functionally likely to matter

[SgtCoDFish]

suggestion(AI): Copy pasting an AI review comment here since it explains it well. I think using fs.Changed might be a good shout - but this is gold-plating stuff, and I don't think this is required.

---

Defaults duplicated in three places → silent-drift risk

csi-lib defines the defaults in manager.go:141-152, options.go redefines them at cmd/app/options/options.go:231-238, and the Helm chart re-states them again in values.yaml and values.schema.json. If csi-lib bumps its defaults in a future release, the csi-driver silently pins to the old values because it always sets GateBackoffConfig when gates are configured (cmd/app/app.go:147-153).

Two possible mitigations, either is fine:

• Preferred: only build GateBackoffConfig when at least one gate-backoff flag was changed by the user; otherwise leave mgrOpts.GateBackoffConfig nil so csi-lib applies its own defaults. pflag.FlagSet.Changed() gives you this per-flag.

if fs.Changed("gate-backoff-duration") || fs.Changed("gate-backoff-factor") ||
fs.Changed("gate-backoff-jitter") || fs.Changed("gate-backoff-cap") {
mgrOpts.GateBackoffConfig = &wait.Backoff{ ... }
}

• This does complicate wiring (needs access to the FlagSet at RunE time), but it preserves the "leaving them unset is a no-op" promise the comment makes.
• Cheaper alternative: add a comment pointing at the exact csi-lib version whose defaults are mirrored (e.g. // Keep in sync with csi-lib@v0.11.0 GateBackoffConfig defaults; see manager.go:141-152.) and treat any csi-lib bump as a prompt to re-audit.

[patyogesh20]

Agreed on the drift risk. TL;DR - I went with proposed preferred option (FlagSet.Changed()) rather than the comment-only mitigation.

I was checking if there are any precedents/established idiom for "don't duplicate a library's internal default", since I didn't want to introduce a one-off pattern. Here is what I found:

• RenewalBackoffConfig (csi-lib's other backoff) has no driver-level flags at all. We just never set it, so csi-lib's default always wins. No duplication, but also no operator override, which we do want for gate-backoff.

• --kube-api-qps/--kube-api-burst in this same file use a zero-value sentinel. Clean, but doesn't transfer here as 0 isn't a safe sentinel for validateGateBackoff duration.

• controller-runtime's manager.Options.LeaseDuration/RenewDeadline/RetryPeriod are *time.Duration, nil-checked internally. This is the cleanest idiom, but it requires the library (csi-lib) to expose nil-able defaults or exported constants like client-go's DefaultQPS/DefaultBurst.

• Changed()- based flag precedence shows up in kubeadm/kube-proxy ComponentConfig loading for exactly this situation: a default that can't be expressed as a safe zero value.

One thing worth calling out explicitly: this is a slightly special case relative to the other config knobs in this driver, because  --gate-backoff-*  exists specifically to give operators optionality to override csi-lib's tuning, unlike RenewalBackoffConfig , which we deliberately don't expose at all. So the fix needs to preserve "operator can override" while still deferring to csi-lib when they don't, which is exactly what  Changed()  gives us.

[patyogesh20]

@SgtCoDFish I have addressed your latest comments; consider giving it one more pass.