AEP-8026: per-vpa-component-configuration

[omerap12]

What type of PR is this?

/kind documentation
/kind feature
/kind api-change

What this PR does / why we need it:

AEP for #7650

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: omerap12

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:

• vertical-pod-autoscaler/OWNERS [omerap12]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[omerap12]

/assign @raywainman

[k8s-triage-robot]

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.

[raywainman]

I really like this @omerap12, thanks for putting this together!

[raywainman]

small nit but I would love to be consistent with the camel-casing of OOM here to match the others, maybe we say evictAfterOomThreshold?

[omerap12]

Fixed in: a10a0e3

[raywainman]

Will we still do some basic validating in the code?

[omerap12]

Yeah, e2e tests will be included: 5b89607

[raywainman]

Big +1 here, if we can keep all of these in the same AEP then I think it becomes a lot easier and more streamlined to add parameters.

One thing that would be nice though is to add a small section for each new parameter we are proposing to add outlining what the parameter does.

What do you think?

[omerap12]

Agree. What do you think about that? 978208e

[adrianmoisey]

Do these API changes need to be feature-gated and go through the process of:

1. Default off
2. Default on
3. GA

I don't think the VPA project really promises a downgrade path, but Kubernetes does. If we use what Kubernetes has defined, then we may need to do this.

[omerap12]

Do these API changes need to be feature-gated and go through the process of:

1. Default off
2. Default on
3. GA

I don't think the VPA project really promises a downgrade path, but Kubernetes does. If we use what Kubernetes has defined, then we may need to do this.

I thought you are on vacation!
But I don't think we need to do the all feature gate process , maybe I'm wrong here..
@raywainman @voelzmo wdyt?

[adrianmoisey]

I thought you are on vacation!

I'm easing back into open source over the next week or so, and playing catch up.

But I don't think we need to do the all feature gate process , maybe I'm wrong here..

I think it depends on what our promise is to the user. If we promise the ability to downgrade by 1 version, then we need to do the feature-gating
If we don't promise anything, then we're good and don't need to feature-gate.

In the past it seems as though we loosely adopt what Kubernetes promises (ability to downgrade), but that doesn't seem to be a formal decision.

[omerap12]

I think it depends on what our promise is to the user. If we promise the ability to downgrade by 1 version, then we need to do the feature-gating
If we don't promise anything, then we're good and don't need to feature-gate.

What does downgrade means in this context? cause you are just adding fields..

[adrianmoisey]

I think it depends on what our promise is to the user. If we promise the ability to downgrade by 1 version, then we need to do the feature-gating
If we don't promise anything, then we're good and don't need to feature-gate.

What does downgrade means in this context? cause you are just adding fields..

Something like this is what I'm thinking:

1. Someone upgrades the VPA to a version including this feature (CRDs and all components upgraded)
2. They then use one of these fields for a VPA
3. They downgrade. I assume the CRD is not downgraded... only a VPA component, to a version that doesn't support the new feature

Their previously-set VPA setting (oomBumpUpRatio, for example) no longer works.

It's not a big deal, but it's how Kubernetes rolls out new features.

[omerap12]

I think it depends on what our promise is to the user. If we promise the ability to downgrade by 1 version, then we need to do the feature-gating
If we don't promise anything, then we're good and don't need to feature-gate.

What does downgrade means in this context? cause you are just adding fields..

Something like this is what I'm thinking:

1. Someone upgrades the VPA to a version including this feature (CRDs and all components upgraded)
2. They then use one of these fields for a VPA
3. They downgrade. I assume the CRD is not downgraded... only a VPA component, to a version that doesn't support the new feature

Their previously-set VPA setting (oomBumpUpRatio, for example) no longer works.

It's not a big deal, but it's how Kubernetes rolls out new features.

I understand. Right now, if someone updates the VPA and sets a different oomBumpUpRatio than the global setting, and then later downgrades, it will go back to the global value.
I can add a feature gate if you think it's needed.

[adrianmoisey]

I understand. Right now, if someone updates the VPA and sets a different oomBumpUpRatio than the global setting, and then later downgrades, it will go back to the global value.
I can add a feature gate if you think it's needed.

Yeah, the downgrade isn't a big problem with this change.
I think the big question is if we want to align with what Kubernetes does, or if we're happy with not supporting a super clean downgrade.

I think the VPA is a lower risk than Kubernetes, so we could get away not worrying about a downgrade, but, someone may expect the same from the VPA as they do from Kubernetes. So I'm on the fence with this one.
I've added an item to the sig-autoscaling meeting (for the 12th May) to discuss it