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
Revert "client-go: remove no longer used finalURLTemplate" #111752
Revert "client-go: remove no longer used finalURLTemplate" #111752
Conversation
The functionality provided by the finalURLTemplate is still used by certain external projects to track the request latency for requests performed to kube-apiserver. Using a template of the URL, instead of the URL itself, prevents the explosion of label cardinality in exposed metrics since it aggregates the URLs in a way that common URLs requests are reported as being the same. This reverts commit bebf5a6. Signed-off-by: André Martins <aanm90@gmail.com>
/test pull-kubernetes-unit |
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. |
the url path is unbounded, each CRD per example will create its own path, the templating doesn't prevent the label cardinality explosion |
ah, I see the disconnection, I wasn't understanding the issue sorry. The Interface uses the url as parameter to keep backwards compatibility, but the method that gathers the metrics only uses the host to avoid the cardinality problem |
/lgtm The interface accepts an URL, we pass the URL without templating because we rely on the implementation to drop the path and use the host only. kubernetes/staging/src/k8s.io/component-base/metrics/prometheus/restclient/metrics.go Lines 169 to 171 in f0bd02c
However, this breaks users that decide to implement their own adapter for the latency metrics, they were relying on the URL to be templated (I don't know how safe that is though) /assign @liggitt @wojtek-t @dgrisonnet The CI failure is legit
|
Signed-off-by: André Martins <aanm90@gmail.com>
3186c73
to
94e7b2b
Compare
@@ -519,14 +519,17 @@ func (r Request) finalURLTemplate() url.URL { | |||
newParams[k] = v | |||
} | |||
r.params = newParams | |||
url := r.URL() | |||
u := r.URL() | |||
if u == nil { |
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.
this can not happen, right? it always return an empty URL , it never returns nil
// URL returns the current working URL.
func (r *Request) URL() *url.URL {
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.
Correct it can't, but otherwise there is no way to ignore the linter AFAIK. Do you have a suggestion for this? 🤔
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.
ah, lol, didn't got that detail
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 pasted the error without looking into it 🙃
/lgtm
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 wonder if the linter guesses that the pointer might be nil based on this check:
if url != nil && r.c.base != nil && strings.Contains(url.Path, r.c.base.Path) {
Since url can't be nil, what would happen if you were to remove the check, would the linter still complain?
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 wonder if the linter guesses that the pointer might be nil based on this check:
if url != nil && r.c.base != nil && strings.Contains(url.Path, r.c.base.Path) {
Since url can't be nil, what would happen if you were to remove the check, would the linter still complain?
No, I think it simply knows that url
is a pointer and we are accessing the pointer without checking if it's not nil.
/assign @yliaog |
/test pull-kubernetes-integration |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: aanm, liggitt 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 |
/milestone v1.25 |
@aanm: You must be a member of the kubernetes/milestone-maintainers GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your Milestone Maintainers Team and have them propose you as an additional delegate for this responsibility. 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. |
We are talking about this PR here: https://kubernetes.slack.com/archives/C2C40FMNF/p1660773038626139 Looks like the consensus is that we wait until |
…-origin-gh-aanm-release-1.25 Automated cherry pick of #111752: Revert "client-go: remove no longer used
…-origin-gh-aanm-release-1.24 Automated cherry pick of #111752: Revert "client-go: remove no longer used
The functionality provided by the finalURLTemplate is still used by
certain external projects to track the request latency for requests
performed to kube-apiserver.
Using a template of the URL, instead of the URL itself, prevents the
explosion of label cardinality in exposed metrics since it aggregates
the URLs in a way that common URLs requests are reported as being the
same.
This reverts commit bebf5a6.
Signed-off-by: André Martins aanm90@gmail.com
What type of PR is this?
/kind bug
/kind cleanup
/kind api-change
/kind regression
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #111750
Special notes for your reviewer:
Please take a look at #111750 for more information
Does this PR introduce a user-facing change?