Skip to content

fix: stop swallowing the client-certificate error#374

Open
xrl wants to merge 1 commit into
etcd-io:mainfrom
xrl:pr/T0-client-cert-error
Open

fix: stop swallowing the client-certificate error#374
xrl wants to merge 1 commit into
etcd-io:mainfrom
xrl:pr/T0-client-cert-error

Conversation

@xrl

@xrl xrl commented Jun 17, 2026

Copy link
Copy Markdown

When an EtcdCluster requests TLS, fetchAndValidateState provisions the operator's client certificate via createClientCertificate. That error was logged and then ignored, so reconciliation proceeded even though the credential the TLS data path depends on was never created — the failure is invisible and surfaces later as a more confusing downstream error.

This returns a requeue with backoff (the existing requeueDuration, matching the sibling error paths in the same function) on failure, so provisioning is retried instead of silently swallowed.

Adds a unit test that drives fetchAndValidateState with a fake client whose scheme omits the cert-manager types (forcing the certificate lookup to fail) and asserts a non-zero RequeueAfter with no reconcileState returned (reconcile does not proceed past cert provisioning).

Refs #370


PR series — operability fixes & TLS

Small single-purpose PRs from live kind-cluster testing of the operator. Each stands alone unless an After is listed. → = this PR.

PR Lands After
Reviewable now — small, any order
🟢→ #374 Requeue instead of swallowing the client-cert provisioning error
🟢 #391 Grant events.k8s.io RBAC so operator Events are actually recorded
🟢 #392 Correlate members[]/leaderID from one health snapshot (consistent leader)
🟢 #393 Propagate user-supplied altNames.ipAddresses into certificates
🟢 #394 Accept day-suffix validityDuration (365d, 100d12h) as documented
🟢 #395 Surface early reconcile errors as a Degraded condition (was empty status)
🟢 #379 Configurable reconcile worker pool (--max-concurrent-reconciles)
🟢 #369 kind-based stress/scale e2e harness (1/3/7 members, churn, quorum watcher)
TLS stack — in order
🟢 #376 Independent spec.tls.{peer,client} surfaces (breaking alpha API)
#377 TLSReady condition + TLS lifecycle Events #376
#378 Multi-member TLS quorum e2e + PeerCANotShared #377
Parked as drafts pending #363
#382 Per-cluster domain metrics on the operator /metrics endpoint
#384 EtcdCluster admission webhooks (consolidating with #328) #363
#386 EtcdBackup CR → object storage (S3/GCS) #363
#387 Automatic quorum-loss disaster recovery (bootstrap-latch guarded) #363

🟢 ready · ⚪ draft

When an EtcdCluster requests TLS, fetchAndValidateState provisions a
client certificate for the operator via createClientCertificate. The
error from that call was logged and then ignored, so reconciliation
continued even though the credential the data path depends on was never
created.

Return a requeue with backoff (the existing requeueDuration, matching the
sibling error paths in this function) on failure so the provisioning is
retried instead of silently swallowed.

Adds a unit test driving fetchAndValidateState with a fake client whose
scheme omits the cert-manager types, forcing the certificate lookup to
fail, and asserts the result is a non-zero RequeueAfter and that no
reconcileState is returned (reconcile does not proceed past cert
provisioning).

Refs etcd-io#370

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Xavier Lange <xrlange@gmail.com>
@k8s-ci-robot

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: xrl
Once this PR has been reviewed and has the lgtm label, please assign jberkus 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

@k8s-ci-robot

Copy link
Copy Markdown

Hi @xrl. Thanks for your PR.

I'm waiting for a etcd-io 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.

Regular contributors should join the org to skip this step.

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.

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants