[noderesourcetopology] complete the contextual logging integration #725
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
k8s-ci-robot
added
release-note-none
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ffromani 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 |
k8s-ci-robot
added
approved
✅ Deploy Preview for kubernetes-sigs-scheduler-plugins canceled.
|
|
/cc @PiotrProkop second and final part of the work begun in #710 |
ffromani
changed the title
|
everything but the last commit is final and ready for review. Still ironing out the last commit. |
ffromani
force-pushed
the
klog-contextual-logging
branch
5 times, most recently
from
339ec79
to
11b0b81
Compare
ffromani
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
/hold I'm now happy with all the changes, but holding while my own final testing is ongoing |
k8s-ci-robot
added
the
do-not-merge/hold
|
/hold after further clarifications about the contextual logging |
ffromani
changed the title
k8s-ci-robot
added
the
do-not-merge/work-in-progress
ffromani
force-pushed
the
klog-contextual-logging
branch
3 times, most recently
from
6392841
to
f1d81da
Compare
ffromani
changed the title
k8s-ci-robot
removed
the
do-not-merge/work-in-progress
|
finally ready. Further tunings will be deferred to future PRs. |
|
/hold cancel |
k8s-ci-robot
removed
the
do-not-merge/hold
|
I'd be happy to squash commits as reviewers suggest |
PiotrProkop
reviewed
Apr 30, 2024
ffromani
force-pushed
the
klog-contextual-logging
branch
from
f1d81da
to
a65dba1
Compare
|
squashed and reformatted the commit message. |
|
Sorry for the delay! |
k8s-ci-robot
added
lgtm
NP, need rebase anyway :) |
After more review and conversations, we have a better understanding of how integration with contextual logging should loom like. First and foremost, injecting loggers would conflict with the very goals of contextual logging. So, let's drop this code we added in kubernetes-sigs#710. The contextual logger doesn't do key/values deduplication. This is let to (some) backends. To avoid log clutter, trim down the extra key/value pairs and add only those we really need to ensure a good troubleshooting experience. Still let's make sure to add critical key/value pairs in the relevant entries, at cost of a possible duplication. When reporting the current assumed resources, the current representation is neither concise nor very human friendly. Additionally, multi-line log entries are harder to process and should be avoided. So let's move to a more concise representation, which turns out not obviously less human friendly and is no longer multiline. Review verbosiness of log entries. Move down to verbose=2 logs which are really key to understand the behavior. We should set a hard limit to log entries to minimize the log spam while keeping at least some observability without requiring v=4 or greater. The level v=4 is usually/often the highest-not-spammy log. When debug logs are needed we often set v=4, and higher verbosity levels are often used only in desperate times. Thus, promote to v=4 the debug logs we should really see. Everywhere else in the kubernetes ecosystem, and most notably in the scheduler, the pod namespace/name pair is called "pod", while we called it "logID". We do it to use the same name for all the flows, being the cache resync (which is driven by time, not by an object) the odd one. It seems better to be externally consistent (with the ecosystem) rather than internally consistent (all the flows in the same plugin), so we rename "logID" to "pod" in the log entries. Signed-off-by: Francesco Romani <fromani@redhat.com>
ffromani
force-pushed
the
klog-contextual-logging
branch
from
a65dba1
to
7098181
Compare
k8s-ci-robot
removed
lgtm
|
/lgtm |
k8s-ci-robot
added
the
lgtm
ffromani
added a commit
to ffromani/scheduler-plugins
that referenced
this pull request
May 27, 2024
before kubernetes-sigs#710 and kubernetes-sigs#725, we logged the container being processed alongside the pod (identified by namespace/name pair). It was dropped by mistake and not deliberately. This is useful information when troubleshooting, so let's add it back. Signed-off-by: Francesco Romani <fromani@redhat.com>
ffromani
added a commit
to ffromani/scheduler-plugins
that referenced
this pull request
May 27, 2024
before kubernetes-sigs#710 and kubernetes-sigs#725, we logged the container being processed alongside the pod (identified by namespace/name pair). It was dropped by mistake and not deliberately. This is useful information when troubleshooting, so let's add it back. Signed-off-by: Francesco Romani <fromani@redhat.com>
ffromani
added a commit
to ffromani/scheduler-plugins
that referenced
this pull request
May 29, 2024
before kubernetes-sigs#710 and kubernetes-sigs#725, we logged the container being processed alongside the pod (identified by namespace/name pair). It was dropped by mistake and not deliberately. This is useful information when troubleshooting, so let's add it back. Signed-off-by: Francesco Romani <fromani@redhat.com>
ffromani
added a commit
to openshift-kni/scheduler-plugins
that referenced
this pull request
May 29, 2024
before kubernetes-sigs#710 and kubernetes-sigs#725, we logged the container being processed alongside the pod (identified by namespace/name pair). It was dropped by mistake and not deliberately. This is useful information when troubleshooting, so let's add it back. Signed-off-by: Francesco Romani <fromani@redhat.com> (cherry picked from commit 7a8afdf)
ichbinblau
pushed a commit
to ichbinblau/scheduler-plugins
that referenced
this pull request
Jun 24, 2024
before kubernetes-sigs#710 and kubernetes-sigs#725, we logged the container being processed alongside the pod (identified by namespace/name pair). It was dropped by mistake and not deliberately. This is useful information when troubleshooting, so let's add it back. Signed-off-by: Francesco Romani <fromani@redhat.com>
AlleNeri
pushed a commit
to AlleNeri/scheduler-plugins
that referenced
this pull request
Jul 26, 2024
before kubernetes-sigs#710 and kubernetes-sigs#725, we logged the container being processed alongside the pod (identified by namespace/name pair). It was dropped by mistake and not deliberately. This is useful information when troubleshooting, so let's add it back. Signed-off-by: Francesco Romani <fromani@redhat.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
This is the second and last part of the contextual logging/logr porting/log cleanup tracked in #709 and begun in #710 . Working on #710, addressing the review comments, and reviewing the changes in kube 1.28 and beyond (see #712) lead to the realization that some better integration is desirable. That's completed in this PR.
Which issue(s) this PR fixes:
Related to #709
Special notes for your reviewer:
Further minor tweaks of the log levels of some key messages are planned, but the vast majority of the work is considered done with this PR.
Does this PR introduce a user-facing change?