-
Notifications
You must be signed in to change notification settings - Fork 4.3k
feat: CPU startup boost in master #9141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
feat: CPU startup boost in master #9141
Conversation
Fix VPA startup boost validation error messages
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: kamarabbas99 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
a687d83 to
419eedc
Compare
|
This PR may require API review. If so, when the changes are ready, complete the pre-review checklist and request an API review. Status of requested reviews is tracked in the API Review project. |
|
/label api-review |
soltysh
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a few comments for logic. From API shadow perspective this lgtm, I'll try to get API approval on it timely :)
| if vpa_api_util.GetUpdateMode(vpa) == vpa_types.UpdateModeOff { | ||
| // If update mode is "Off", we don't want to apply any recommendations, | ||
| // but we still want to unboost. | ||
| original, err := annotations.GetOriginalResourcesFromAnnotation(pod) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you're using annotations for keeping values from before the boost, what happens when the annotation is removed? Do you inform/warn users in some way about that fact?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When the annotations gets removed we just apply the recommendations which isnt too bad but if the vpa mode is
set to UpdateModeOff, the pod will remain boosted forever(but i think it might not be too common to use startup boost with update mode off).
Is there a way to warn users when they remove annotations?
| } | ||
| } | ||
|
|
||
| func TestGetOriginalResourcesFromAnnotation(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest adding an error test case, where the annotation read will fail as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are already test cases that cover all scenarios:
- no annotation
- Invalid json annotation
- successful
vertical-pod-autoscaler/pkg/apis/autoscaling.k8s.io/v1/types.go
Outdated
Show resolved
Hide resolved
9808ee6 to
245ad93
Compare
245ad93 to
d8edd78
Compare
| // durationSeconds indicates for how long to keep the pod boosted after it goes to Ready. | ||
| // Defaults to 0. | ||
| // +optional | ||
| DurationSeconds *int32 `json:"durationSeconds,omitempty" protobuf:"varint,4,opt,name=durationSeconds"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you also update the AEP to reflect this?
(In another PR I guess)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated in the same commit, should I make a new PR just for AEP?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes please.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| factor: | ||
| description: |- | ||
| factor specifies the factor to apply to the resource request. | ||
| This field is required when Type is "Factor". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where is this requirement enforced? I expected to see x-kubernetes-validations at the cpu level or something similar to enforce this
| description: |- | ||
| quantity specifies the absolute resource quantity to be used as the | ||
| resource request and limit during the boost phase. | ||
| This field is required when Type is "Quantity". |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where is this requirement enforced? I expected to see x-kubernetes-validations at the cpu level or something similar to enforce this
What type of PR is this?
/kind feature
/kind api-change
What this PR does / why we need it:
The CPU startup boost changes were done on experimental branch, moving this to master.
Special notes for your reviewer:
Since #8813 didnt get submitted on time, it was hard to maintain it so as @adrianmoisey suggested I created new PR from local branch directly into master. All of the commits in this PR except the last one have already been reviewed.
Does this PR introduce a user-facing change?
Which issue(s) this PR fixes:
#7862
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: