Pass the whole VPA into cappingRecommendationProcessor.Apply() #7527
Conversation
The current log message for when no container is found is very misleading and can cause confusion. This passes the entire VPA object into that function, in order for it to create a log file with the relevant VPA name in it. It kinda feels like surgery with a scalpel, any alternative approaches would be appreciated.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: adrianmoisey The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| pod *apiv1.Pod) (*vpa_types.RecommendedPodResources, ContainerToAnnotationsMap, error) { | ||
| // TODO: Annotate if request enforced by maintaining proportion with limit and allowed limit range is in conflict with policy. | ||
|
|
||
| policy := vpa.Spec.ResourcePolicy.DeepCopy() |
There was a problem hiding this comment.
Can we check for some edge cases ( just to avoid panic )?
if vpa == nil {
return nil, nil, fmt.Errorf("cannot process nil vpa")
}
if pod == nil {
return nil, nil, fmt.Errorf("cannot process nil pod")
}
if vpa.Status.Recommendation == nil {
return nil, nil, nil // This matches existing behavior for no recommendation
}There was a problem hiding this comment.
Should be fixed in 13d6ffa
| pod *v1.Pod) (*vpa_types.RecommendedPodResources, ContainerToAnnotationsMap, error) { | ||
| recommendation := podRecommendation | ||
|
|
There was a problem hiding this comment.
Same for here ( not sure if needed but just my opinion ):
if vpa == nil {
return nil, nil, fmt.Errorf("cannot process nil vpa")
}
if vpa.Status.Recommendation == nil {
return nil, nil, nil
}There was a problem hiding this comment.
Should be fixed in 13d6ffa
There was a problem hiding this comment.
Should we check pod here as well?
There was a problem hiding this comment.
I thought about adding a check there, but all that function does is pass Pod on to another function call.
Since this function doesn't actually do anything to Pod, I figured the guards could be in the functions that would do something with Pod.
There was a problem hiding this comment.
If my comments make sense to you, we could add more unit tests to cover those edge cases. For example:
func TestApplyWithNilVPA(t *testing.T) {
pod := test.Pod().WithName("pod1").AddContainer(test.Container().WithName("ctr-name").Get()).Get()
processor := NewCappingRecommendationProcessor(&fakeLimitRangeCalculator{})
res, annotations, err := processor.Apply(nil, pod)
assert.Error(t, err)
assert.Nil(t, res)
assert.Nil(t, annotations)
}
func TestApplyWithNilPod(t *testing.T) {
vpa := test.VerticalPodAutoscaler().WithContainer("container").Get()
processor := NewCappingRecommendationProcessor(&fakeLimitRangeCalculator{})
res, annotations, err := processor.Apply(vpa, nil)
assert.Error(t, err)
assert.Nil(t, res)
assert.Nil(t, annotations)
}|
Nice cleanup, thank you :) /lgtm |
| pod *apiv1.Pod) (*vpa_types.RecommendedPodResources, ContainerToAnnotationsMap, error) { | ||
| // TODO: Annotate if request enforced by maintaining proportion with limit and allowed limit range is in conflict with policy. | ||
|
|
||
| policy := vpa.Spec.ResourcePolicy.DeepCopy() |
There was a problem hiding this comment.
I like the defensiveness here, in practice the code before could have allowed someone to mutate the object and cause all kinds of weird behavior.
Curious if you noticed any issue anywhere in this function that could have caused unwanted mutation?
There was a problem hiding this comment.
That being said, we might inherit some performance penalties here (though should be very small) and I don't think we generally do this anywhere else in the codebase so could go either way here.
There was a problem hiding this comment.
I've removed them in e9c1c1c
For some reason I thought they were needed. When making this PR I was a little rushed, since I was moving laptops and wanted my work-in-progress code pushed.
Anyway, the problem I was facing was actually fixed in e277df0, but for some reason I thought that DeepCopy fixed it
|
Thanks for the reviews. I was actually rushed when making this, so still need to do a cleanup and respond to comments. |
It's unneeded
And add tests
|
/lgtm |
|
/unhold |
| pod *v1.Pod) (*vpa_types.RecommendedPodResources, ContainerToAnnotationsMap, error) { | ||
| recommendation := podRecommendation | ||
|
|
There was a problem hiding this comment.
Should we check pod here as well?
| return nil, nil, fmt.Errorf("cannot process nil vpa") | ||
| } | ||
| if vpa.Status.Recommendation == nil { | ||
| return nil, nil, nil |
There was a problem hiding this comment.
I actually wonder if this should be an error case...
The processors are generally "adjusting" the recommendation one at a time. If there is no recommendation to adjust then this feels like an error case to me.
@omerap12 or @adrianmoisey are you seeing a case where this should be allowed?
There was a problem hiding this comment.
Oh wait I see that this is being done in the capping processor. Perhaps it is best to be consistent.
However I wonder if this can eventually be made more strict and turned into an error.
There was a problem hiding this comment.
I am assuming that this case should never happen
|
/lgtm |
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
The current log message for when no container is found is very misleading and can cause confusion.
This passes the entire VPA object into that function, in order for it to create a log file with the relevant VPA name in it.
It kinda feels like surgery with a scalpel, any alternative approaches would be appreciated.
Take a look at #7491 to see the confusion it can cause.
Which issue(s) this PR fixes:
Fixes #7491
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: