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
MON-3548: Merge tag v2.10.1 #106
MON-3548: Merge tag v2.10.1 #106
Conversation
Co-authored-by: Mario Constanti <github@constanti.de>
Sync `main` with `release-2.9`
go.mod: Bump to k8s 1.27.x
Fix cyclomatic complexity in KSM files
feat: Enable semantic commit messages
Signed-off-by: Maxime Leroy <19607336+maxime1907@users.noreply.github.com>
Signed-off-by: Maxime Leroy <19607336+maxime1907@users.noreply.github.com>
docs: update multi-arch version to v2.9.2 in README.md
Adds a paragraph on RBAC and removes the outdated information on setting the customresource in the --resources flag. Signed-off-by: Manuel Rüger <manuel@rueg.eu>
docs: Document RBAC and remove outdated info
In order to better identify, prioritize, and debug webhook latency issues it is important to have a metric that would point to the resource it is responsible for. However, it is not possible to have that dimension in the metrics exposed by Kubernetes because of the unbound cardinality that such a label would have. The name of the webhook could be an alternative since it usually contains some information about the resource that the webhook targets, however this is not very practical to use in multi-tenants environments. A solution for these kind of platform is to tie a specific webhook to a namespace in order to be able to know which tenant manages it and take actions depending on that. This is achieveable by leveraging the client config information of webhooks configured via WebhookConfiguration resources since Services are namespaced objects. With these new metrics, users will be able to split the alerting severity of webhook latency / rejection rate per namespace on top of being able to do it based on the webhook name. This is key in environment where administrators don't have control over the webhooks installed by the various tenants. Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
build: Reorder CI steps to use go mod cache
chore: Update dependencies
I will be removing myself from the maintainers role due to available time to work on KSM. Signed-off-by: fpetkovski <filip.petkovsky@gmail.com>
…maintainer chore: Remove myself from maintainers
Signed-off-by: Manuel Rüger <manuel@rueg.eu>
fix: Add filtering for Lease metrics
feat: Add webhooks client config service metrics
…estamp feat(pvc): support kube_persistentvolumeclaim_deletion_timestamp
Signed-off-by: Pranshu Srivastava <rexagod@gmail.com>
Additionally bump x/net to v0.17.0 on `main` as well. Signed-off-by: Pranshu Srivastava <rexagod@gmail.com>
chore: Restructure `release-2.10` for `v2.10.1`
Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
/cc @rexagod |
@dgrisonnet: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
/lgtm Only the following files' diffs differ, which makes sense.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dgrisonnet, 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 |
FYI I can see a |
I tried pulling the updated manifests in CMO by revendoring kube-prometheus but for some reasons, make update + generate didn't fetch the 2.10.1 ksm manifests. If any of you have some time to look into it, that would very appreciated |
@rexagod are you talking about #105? It seems unrelated to this PR. @dgrisonnet CMO is pinned to the main branch of kube-prometheus which is itself pinned to the main branch of kube-state-metrics. Why do you need the updated jsonnet from ksm? |
I just wanted to align to have the correct annotations. That how I recalled we did it before. Yeah I saw that it was pinned to main. When I updated the lock file pointed to the right commit but regenerating didn't get the new ksm version annotations. |
Component versions are handled separately and will be synced automatically when this PR is merged. |
Ah, it seems I somehow missed #105. I'll open up a PR to remove the |
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.
We need a JIRA ticket to merge this. Looking at the changelog, I don't see a bug that we could "leverage" but maybe I missed something. It's also ok to create a ticket in the MON project and link it here.
/retitle MON-3548: Merge tag v2.10.1 |
@rexagod: No Jira issue is referenced in the title of this pull request. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@dgrisonnet: This pull request references MON-3548 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.15.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/jira refresh |
[ART PR BUILD NOTIFIER] This PR has been included in build kube-state-metrics-container-v4.15.0-202312060008.p0.g80d41fa.assembly.stream for distgit kube-state-metrics. |
What this PR does / why we need it:
How does this change affect the cardinality of KSM: (increases, decreases or does not change cardinality)
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #