-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Fix NPE in vpa-updater when Pod owner isn't scalable #6712
Fix NPE in vpa-updater when Pod owner isn't scalable #6712
Conversation
Does it replicate if we just make the owner be a ConfigMap or any other resource? |
I would prefer a test, otherwise lgtm. |
Great Idea! I've replicated it by setting the |
@kwiesmueller I ended up taking a simpler approach, outlined in the PR original comment above. WDYT? |
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.
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kwiesmueller, voelzmo The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/cherry-pick vpa-release-1.1 Edit: seems like the bot doesn't pick this up, I ended up cherry-picking it manually to |
…-npe-to-release-1.1 [vpa-release-1.1] Cherry-pick of #6712: Fix NPE in vpa-updater when Pod owner isn't scalable
I hoped to update to 1.1.0 to see if #6705 is addressed there, but I'm stuck behind this. Is there a new release planned soon? |
We'll work on a 1.1.1 release this week. |
Hi! Just saw that the other issue was referenced here. @akloss-cibo do you have an update on whether #6705 was addressed for you? More info on your theory around this would be appreciated too. Perhaps best to speak in the open issue rather than here :) Thank you! |
What type of PR is this?
/kind bug
What this PR does / why we need it:
The method
ctrlFetcher.FindTopMostWellKnownOrScalable
returnsnil
without an additionalerror
, when there is no owner that is either scalable (implementing the/scale
subresource) or is well-known. In this case, just skip the current Pod, as it cannot be controlled by a VPA.Which issue(s) this PR fixes:
Fixes #6709
Special notes for your reviewer:
This PR adds two tests to make sure this cannot regress:
vertical-pod-autoscaler/pkg/target/controller_fetcher/controller_fetcher_test.go
gets the new testcasecustom resource with no scale subresource
which ensures that for a Pod, which is not under VPA control and has anownerRef
to a custom resource that doesn't implement/scale
, the methodFindTopMostWellKnownOrScalable
returnsnil
,nil
vertical-pod-autoscaler/pkg/utils/vpa/api_test.go
gets an additional test assertion which uses a fakecontrollerFetcher
, which always returnsnil
to make sure thatGetControllingVPAForPod
can deal with anil
,nil
response fromctrlFetcher.FindTopMostWellKnownOrScalable
Does this PR introduce a user-facing change?