Skip to content

Conversation

@kamarabbas99
Copy link
Contributor

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?

Users can configure a startupBoost policy in the VPA spec. 

Which issue(s) this PR fixes:

#7862

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

- [KEP]: (https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler/enhancements/7862-cpu-startup-boost#aep-7862-cpu-startup-boost)

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. kind/feature Categorizes issue or PR as related to a new feature. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API do-not-merge/needs-area cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. area/vertical-pod-autoscaler labels Jan 28, 2026
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: kamarabbas99
Once this PR has been reviewed and has the lgtm label, please assign adrianmoisey 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 k8s-ci-robot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Jan 28, 2026
@kamarabbas99 kamarabbas99 force-pushed the resolve-conflicts-cpu-boost branch 5 times, most recently from a687d83 to 419eedc Compare January 28, 2026 20:14
@k8s-triage-robot
Copy link

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.

@kamarabbas99
Copy link
Contributor Author

/cc @soltysh
Do you mind doing API review(if left) on this instead of #8813 where you previously left comments?

@k8s-ci-robot k8s-ci-robot requested a review from soltysh January 28, 2026 20:56
@soltysh
Copy link
Contributor

soltysh commented Jan 29, 2026

/label api-review

@k8s-ci-robot k8s-ci-robot added the api-review Categorizes an issue or PR as actively needing an API review. label Jan 29, 2026
@soltysh soltysh moved this to Backlog in API Reviews Jan 29, 2026
Copy link
Contributor

@soltysh soltysh left a 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)
Copy link
Contributor

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?

Copy link
Contributor Author

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) {
Copy link
Contributor

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.

Copy link
Contributor Author

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:

  1. no annotation
  2. Invalid json annotation
  3. successful

@liggitt liggitt moved this from Backlog to Changes requested in API Reviews Jan 29, 2026
@kamarabbas99 kamarabbas99 force-pushed the resolve-conflicts-cpu-boost branch 2 times, most recently from 9808ee6 to 245ad93 Compare February 2, 2026 19:52
@kamarabbas99 kamarabbas99 force-pushed the resolve-conflicts-cpu-boost branch from 245ad93 to d8edd78 Compare February 2, 2026 21:31
// 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"`
Copy link
Member

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)

Copy link
Contributor Author

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes please.

Copy link
Contributor Author

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".
Copy link
Member

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".
Copy link
Member

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

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

Labels

api-review Categorizes an issue or PR as actively needing an API review. area/vertical-pod-autoscaler cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/feature Categorizes issue or PR as related to a new feature. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files.

Projects

Status: Changes requested

Development

Successfully merging this pull request may close these issues.

8 participants