fix: report rollout status against the Deployment's own spec.replicas - #444
Open
nominal-charles wants to merge 1 commit into
Open
fix: report rollout status against the Deployment's own spec.replicas#444nominal-charles wants to merge 1 commit into
nominal-charles wants to merge 1 commit into
Conversation
The DeploymentHandler rollout gate compared the Deployment's Available/Ready/UpdatedReplicas to config.replicas. When replicas are managed externally -- for example an autoscaler scaling the Deployment after a spec.patches entry removes /spec/replicas -- the operator no longer sets spec.replicas, so config.replicas never matches the live count and the SpiceDBCluster reports a RollingDeployment condition that never clears (and requeues every 2s). Measure the rollout against the live Deployment's own spec.replicas instead, falling back to config.replicas when that field is unset, using the same completion signals as `kubectl rollout status`. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅ |
Author
|
I have read the CLA Document and I hereby sign the CLA |
nominal-charles
marked this pull request as ready for review
August 27, 2026 15:36
authzedbot
added a commit
to authzed/cla
that referenced
this pull request
Aug 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The operator reports a perpetual
RollingDeploymentcondition when aSpiceDBCluster's Deployment has its replica count managed by something other than the operator.DeploymentHandlergates rollout completion on the Deployment'sAvailable/Ready/UpdatedReplicasall equallingconfig.replicas. That holds while the operator ownsspec.replicas, but the operator's ownspec.patchesfeature lets a user remove/spec/replicasfrom the applied Deployment so an external autoscaler (HPA/KEDA) can own the count. Once that happens the operator no longer setsspec.replicas, the live count no longer tracksconfig.replicas, and the condition never clears — the cluster reports e.g.6/8 availableindefinitely while the handler requeues every 2s. The same mismatch can occur transiently whenconfig.replicasis changed mid-rollout.Change
Measure rollout completion against the live Deployment's own
spec.replicasrather thanconfig.replicas, falling back toconfig.replicasonly when the live field is unset. Completion now uses the same signals askubectl rollout status: the latest generation has been observed, every desired replica has been updated to the current pod template and is available, and no replicas from a previous revision remain. The waiting-message denominators report the live desired count.The logic lives in two small package-private helpers,
desiredDeploymentReplicasanddeploymentRolloutComplete. No API or CRD change.Tests
Added focused unit tests for both helpers and a
TestEnsureDeploymentHandlercase covering a fully-available Deployment whose external replica count differs fromconfig.replicas(previously stuck rolling, now clears).go test -race ./...passes andgo mod tidyis clean; e2e was not run locally.Fixes #108