-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Deprecate VPA #1835
Deprecate VPA #1835
Conversation
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.
Thanks.
/lgtm
/hold
kind: CustomResourceStateMetrics | ||
spec: | ||
resources: | ||
- groupVersionKind: | ||
group: autoscaling.k8s.io | ||
kind: "VerticalPodAutoscaler" | ||
version: "v1" | ||
metrics: | ||
- name: "generation" | ||
help: "VPA Generation" | ||
each: | ||
type: Gauge | ||
gauge: | ||
path: [metadata, generation] |
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.
Could we provide them with a manifest that generates exactly the same metrics as we had before? I know that we won't be able to get the exact same names so it would get great to also point the name changes.
| kube_verticalpodautoscaler_spec_updatepolicy_updatemode | Gauge | `namespace`=<namespace> <br> `target_api_version`=<api version> <br> `target_kind`=<target kind> <br> `target_name`=<target name> <br> `update_mode`=<foo> <br> `verticalpodautoscaler`=<vertical pod autoscaler name> | EXPERIMENTAL | | ||
## DEPRECATION NOTICE | ||
|
||
From v2.8.0 onwards, `vericalpodautoscalers` will be removed from the list of default resources. This means that specifying that in the `--resource` flag will **not** generate metrics for the same. In order to generate `verticalpodautoscalers` metrics, you will have to explicitly specify it in `--custom-resource-state-config*` (either the inline yaml, or the configuration file), like so: |
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 v2.6.0 has already been released, we should only start removing VPA in v2.9.0 since the deprecation period should be of at least 2 releases.
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.
IMHO, we should bump version to v3 if we remove VPA metrics.
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.
Breaking changes used to be reserved for major releases when following semantic versioning, but what we've seen in recent years is that projects with only minor releases are healthy and can still handle breaking changes properly as long as they have clear deprecation policies, which is the case for Kubernetes for example. IMHO major releases should only be reserved for major rewrites, which don't include VPA metrics removal. If we are not confident that the deprecation period is enough, I am fine with increasing it, but I don't think waiting for a major release is the right call here.
What do you think @fpetkovski?
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 can understand that major releases can become quite painful with go versioning. Personally, I prefer going with the least surprise for users. Users won't be happy when their VPA metrics are gone and they did not see it coming.
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.
The problem is that there is no reason to cut a new major today besides removing the VPA metrics, which is not a big enough reason to justify a new major version in my opinion. Leaving a long enough deprecation period should already be good enough to not surprise the users. At the very least if we are not confident enough that our users are going through our changelogs, we can add a log line when the vpa store is used saying that it is deprecated and will be removed in version x.y.z.
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.
Experimental features should not have stability guarantees.
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.
Apologies here, I wasn't aware that VPA never made it stable. I'm fine with deprecating and removing without bumping major here. Thanks for explaining!
The unit tests are failing, you need to the update the test metadata to include the deprecation notice: https://github.com/kubernetes/kube-state-metrics/blob/master/internal/store/verticalpodautoscaler_test.go#L33-L40 |
3583628
to
40ca779
Compare
Moved to v3, ready for review. |
I am still very much against cutting a new major version of ksm just for deprecating VPA metrics. This is not an overhaul of the codebase, we are just deprecating some metrics and replacing them with new ones. See it as a renaming of metrics rather than a complete removal. Also, it is worth noting that all the VPA metrics are experimental so although they have been in the codebase for a while, users shouldn't expect them to never change. Holding until we've reached a consensus. |
Yeah, cutting a release for deleting experimental metrics seems a bit much to me too. |
Reverted to |
Deprecate VPA metrics in v2.9.0. Signed-off-by: Pranshu Srivastava <rexagod@gmail.com>
/approve |
@mrueg Can you please |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fpetkovski, mrueg, rexagod 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 |
So what are the alternatives now to get those metrics ? Sry starting with vpa just to have free recommendations instead of paying 15k to some random saas. |
There is a doc explaining how to get them back in https://github.com/kubernetes/kube-state-metrics/blob/main/docs/customresourcestate-metrics.md#verticalpodautoscaler |
stdout
).Signed-off-by: Pranshu Srivastava rexagod@gmail.com
How does this change affect the cardinality of KSM: No change (VPA metrics will be removed in v2.9.0).
Which issue(s) this PR fixes: Partially targets #1718.