Repository navigation
feat: Report per-cluster rollout state in GET /profile - #198
Merged
gianlucam76 merged 1 commit intoOct 23, 2026
Merged
Conversation
When a profile sets maxUpdate, only that many clusters are updated at a time. The other matching clusters are queued and still run the previous configuration. GET /profile returned only the deployment status from each cluster's current ClusterSummary, so a queued cluster looked provisioned and the dashboard could not tell the clusters apart. This adds the rollout state to the response. Each entry in matchingClusters gets an optional rolloutState: - updated: the cluster has the latest version of the profile - updating: the latest version is being deployed to the cluster - waiting: the cluster is queued because maxUpdate is reached - paused: the cluster is paused, the rollout skips it - notReady: the cluster is not ready to be configured, the rollout skips it The state comes from Status.UpdatedClusters and Status.UpdatingClusters of the ClusterProfile or Profile. Paused and ready come from the cluster cache the manager already keeps, so the change adds no API calls. A paused cluster is reported as paused even if it appears in one of the lists, since it will not be updated. notReady is only reported for a cluster that would otherwise be waiting. The response also gets a rollout summary with the number of clusters per state and the resolved maxUpdate (a percentage is applied to the number of matching clusters and rounded up, as the profile controller does). It is only present while a rollout is pending, that is, while one of the two lists is not empty. The profile controller resets both lists once every matching cluster is synced, so neither field is reported for a settled profile. A paused cluster still gets rolloutState paused in that case. Existing fields are unchanged. The new ones are omitted when empty.
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
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.
When a profile sets maxUpdate, only that many clusters are updated at a time. The other matching clusters are queued and still run the previous configuration. GET /profile returned only the deployment status from each cluster's current ClusterSummary, so a queued cluster looked provisioned and the dashboard could not tell the clusters apart.
This adds the rollout state to the response.
Each entry in matchingClusters gets an optional rolloutState:
The state comes from Status.UpdatedClusters and Status.UpdatingClusters of the ClusterProfile or Profile. Paused and ready come from the cluster cache the manager already keeps, so the change adds no API calls. A paused cluster is reported as paused even if it appears in one of the lists, since it will not be updated. notReady is only reported for a cluster that would otherwise be waiting.
The response also gets a rollout summary with the number of clusters per state and the resolved maxUpdate (a percentage is applied to the number of matching clusters and rounded up, as the profile controller does). It is only present while a rollout is pending, that is, while one of the two lists is not empty. The profile controller resets both lists once every matching cluster is synced, so neither field is reported for a settled profile. A paused cluster still gets rolloutState paused in that case.
Existing fields are unchanged. The new ones are omitted when empty.