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
Migrate scheduler to structured logging #105841
Comments
File level breakup
|
Thanks @pchan, |
/triage accepted |
/sig instrumentation |
@shivanshu1333: 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 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. |
/milestone v1.23 |
No, this is unrelated to tracing. What we need is contextual logging:
This cannot be done without passing the logger instance with the additional value through the entire call chain where log messages are emitted as part of scheduling. In other words, it cannot be done with the current global logger in klog. I am working on a KEP for this. |
Yes, @pohly is on point, we need to have contextual logging for this. |
Maybe I can help to migrate the |
BTW, I think we can divide it into 4 part as @shivanshu1333 said. I have tried to divide it into 4 parts:
|
Yes, @jyz0309 the partition looks good, yes you can pick the part 3 |
I'm happy to migrate Part 1 and Part 2, you can assign that to me |
A note to contributors: |
/assign |
@shivanshu1333 and others Thank you. I initially thought it should be divided by component (framework, internal) but I guess even this division will work. Please let me know if it makes sense to add another column in the table, that tracks migration status (link to issue). I will make sure to review the changes. |
Yes, it's good to have a column tracking the PR status🙂 |
I will add a column to track the PR~ |
The following files have been removed and no longer need to be traced.
|
Have deleted it. |
|
All of the PRs are out 🎉 |
Complete migration of scheduler depends on resolution of ((106258 or 106276) and (106262)) |
Hi 👋 Im the bug triage shadow. Since we're in code freeze for 1.23, i wanted to check if we can move this issue to milestone 1.24. |
@jyotimahapatra I think that this issue is just blocked on #106305 |
But even if that PR gets merged, the conversion will still not be complete? We need to track: |
Ok, only #106305 will go in 1.23 as we just need approval. |
Hi all, Bug triage for 1.24 here. Wanted to check what's the expectation for this issue w.r.t 1.24? Is it still relevant and planned to be completed? Also, I see quite a few dependencies in its history - would be great to get an updated summary of blockers if any, and see whether 1.24 is still a relevant target. Thanks! |
#108159 should finish the conversion. |
fixed by #108159 |
What would you like to be added?
Enhance scheduler logging and address current issues.
Authors
What to include in your PR
Subject: "Migrate to structured logging"
SIGs: instrumentation, node
Priority: important-soon
Kind: cleanup
HOW TO: Read the structured logging migration guide.
Please reference this issue for scheduler migrations.
Before you submit your PR, check to see if someone has already migrated that component: https://github.com/kubernetes/kubernetes/pulls?q=is%3Apr+is%3Aopen+structured+log+label%3Asig%2Fnode
Reviewers:
Read through the migration guide above. Use the PR query above to find PRs to review.
Why is this needed?
To get the benefits of structured logging.
kubernetes/enhancements#1602
/wg structured-logging
/sig scheduling
/area logging
/priority important-longterm
/kind cleanup
/cc @kubernetes/wg-structured-logging-reviews
/cc @damemi
The text was updated successfully, but these errors were encountered: