fix: publish scale selectors for user-managed HPAs#591
Open
yankay wants to merge 1 commit into
Open
Conversation
yankay
changed the title
yankay
requested review from
Ronkahn21,
danbar2,
gflarity,
sanjaychatterjee,
shayasoolin and
unmarshall
as code owners
yankay
changed the title
yankay
force-pushed
the
feat/improve-scale-target-discoverability
branch
from
d140bbb to
fb99983
Compare
shayasoolin
reviewed
May 11, 2026
Contributor
shayasoolin
left a comment
shayasoolin
left a comment
There was a problem hiding this comment.
Nice, thanks for your contribution!
What about the PCS level? It's also scalable, does it need a similar handling or is its scale resource always published already?
yankay
force-pushed
the
feat/improve-scale-target-discoverability
branch
from
fb99983 to
6d43732
Compare
Contributor
Author
|
Thanks @shayasoolin — good catch. The PCS |
yankay
force-pushed
the
feat/improve-scale-target-discoverability
branch
3 times, most recently
from
1cd7d9e to
bea9fd3
Compare
Grove only published the /scale subresource selector on PodClique and PodCliqueScalingGroup when Grove-managed autoscaling was configured. That blocks user-managed HPAs, because the HPA controller reads the selector from the target's /scale subresource and fails when it is missing. PodCliqueSet, standalone PodClique, and PodCliqueScalingGroup now publish their scale selectors. PodCliques that belong to a PodCliqueScalingGroup still do not publish their own selector, because they should be scaled through the PCSG target. Adds user-guide documentation for using generated names in user-managed HPAs, and unit tests covering: - PCS publishes a selector - standalone PCLQ with/without ScaleConfig publishes a selector - PCSG-member PCLQ never publishes a selector, regardless of ScaleConfig - PCSG with/without ScaleConfig publishes a selector - PCSG whose name is not present in the PCS template does not publish Fixes ai-dynamo#158 Signed-off-by: Kay Yan <kay.yan@daocloud.io>
yankay
force-pushed
the
feat/improve-scale-target-discoverability
branch
from
bea9fd3 to
2620f03
Compare
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
2 participants
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.
What type of PR is this?
/kind bug
What this PR does / why we need it:
Grove currently publishes the
/scaleselector for PodClique and PodCliqueScalingGroup only when Grove-managed autoscaling is configured. That blocks user-managed HPAs, because the HPA controller reads the selector from the target's/scalesubresource and fails when it is missing.This PR makes PodCliqueSet, standalone PodClique, and PodCliqueScalingGroup always publish their scale selector. PodCliques that belong to a PodCliqueScalingGroup still do not publish their own selector, because they should be scaled through the PCSG target.
How to use:
kubectl get pcs <pcs-name>kubectl get pcsg -l app.kubernetes.io/part-of=<pcs-name>kubectl get pclq -l app.kubernetes.io/part-of=<pcs-name>scaleTargetRefwithkind: PodCliqueSet,PodCliqueScalingGroup, orPodClique.See
docs/user-guide/02_pod-and-resource-naming-conventions/02_naming-conventions.mdfor the full example.Which issue(s) this PR fixes:
Fixes #158
Special notes for your reviewer:
Scope intentionally avoids new API fields, labels, or printer columns.
PCS-level handling was added in response to review feedback. The test matrix in
reconcilestatus_test.gofor each of PodCliqueSet / PodClique / PodCliqueScalingGroup documents which resources now (or still do not) publish a selector.Does this PR introduce a API change?
Additional documentation e.g., enhancement proposals, usage docs, etc.: