-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
KEP 3288: Split stdout and stderr log stream #3289
KEP 3288: Split stdout and stderr log stream #3289
Conversation
ac18b66
to
0d466c6
Compare
0d466c6
to
ec99926
Compare
/cc @mrunalp Hi! Please take a look when you are available 🚀 |
<!-- | ||
What other approaches did you consider, and why did you rule them out? These do | ||
not need to be as detailed as the proposal, but should include enough | ||
information to express the idea and why it was not acceptable. | ||
--> |
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 presume “just one multiplexed log stream” is the only alternative we could consider here?
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.
Did you mean we return the combined stdout and stderr and let the client somehow filter out the unwanted stream?
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.
Another option could be kubectl log directing these 2 streams to stdout/stderr. The downside of that approach would be distinguishing the errors from kubectl log vs. what's coming from the container process.
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.
kubectl log directing these 2 streams to stdout/stderr
That actually sounds like something that'd be useful to offer, and doesn't conflict with this KEP.
return the combined stdout and stderr and let the client somehow filter out the unwanted stream?
If an API client got a stream of CRI-format logs, the demultiplexing could be client side.
To be clear, I wouldn't implement that. We should list the alternative and then briefly explain why the approach we've selected is better.
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.
+1 on listing alternative explicitly
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 have updated the Alternatives
section to describe this alternative approach.
Thanks for making the proposal. Thanks @mrunalp to bring this up to today's SIG Node. We quickly discussed it at the meeting earlier, and will track it with 1.25 release. Thanks! |
... | ||
// If set, return the given log stream of the container. | ||
// Otherwise, the combined stdout and stderr from the container is returned. | ||
// Available values are: "stdout", "stderr", "" (empty string). |
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'd suggest to have "all" as an available value so it can be set explicitly to all
- it will be more user friendly than explicit empty string or omitted parameter.
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 am up for that and I have added "all" as available value.
// If set, return the given log stream of the container. | ||
// Otherwise, the combined stdout and stderr from the container is returned. | ||
// Available values are: "stdout", "stderr", "" (empty string). | ||
Stream string |
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.
is it a string for implementation simplicity or expect any other values to be added later? Perhaps a custom type with three constants instead?
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.
Perhaps a custom type with three constants instead?
Yeah I think this is better, I have updated the proposal.
} | ||
``` | ||
|
||
### Changes of kubelet |
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.
will there be any issues with TailLines
log option? What will be the behavior of this log option when only one stream was specified? (I haven't looked deep in the code)
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.
will there be any issues with TailLines log option?
If TailLines
is set, only the last N lines in the log file whose stream match the one user specified would be returned.
What will be the behavior of this log option when only one stream was specified?
Then only that log stream from the beginning would be returned.
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 haven't looked into code, I just anticipate possible additional changes needed to ensure that the counting of TailLines happens properly and only logs from a specified stream were counted. Definitely add this to the test plan section
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 just anticipate possible additional changes needed to ensure that the counting of TailLines happens properly and only logs from a specified stream were counted.
Actually my original thought is slightly different, I expected kubelet still examine the last TailLines
of the log file, but only returns lines that matches the stream user specified.
I also understand my original thought is easy to implement, though it might confuse users. I agree that the most intutive way is only counting logs from a specified stream, and it would require extra work to be done in kubelet.
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.
+1 on counting logs from a specified stream.
328368c
to
3059d92
Compare
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.
/lgtm
this feels small enough to include into 1.25. It's important to ensure that the test coverage is there
/assign @derekwaynecarr |
|
||
Yes. | ||
|
||
###### What happens if we reenable the feature if it was previously rolled back? |
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.
requires an answer, but since this is not persisted, I don't think there's a concern here.
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.
Updated
|
||
###### What happens if we reenable the feature if it was previously rolled back? | ||
|
||
###### Are there any tests for feature enablement/disablement? |
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.
requires an answer
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.
Updated
minor PRR comments and then PRR lgtm |
The failed tests seems to be caused by a recent merged PR #3281 |
PRR lgtm. The sig still owns review of the overall feature. /approve |
@deads2k Thanks a lot! Gently ping @dchen1107 @derekwaynecarr for final approval 🚀 . It would be great if we could ship it before enhancements freeze. |
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.
/lgtm
Signed-off-by: Jian Zeng <anonymousknight96@gmail.com>
Signed-off-by: Jian Zeng <anonymousknight96@gmail.com>
Signed-off-by: Jian Zeng <anonymousknight96@gmail.com>
Signed-off-by: Jian Zeng <anonymousknight96@gmail.com>
Signed-off-by: Jian Zeng <anonymousknight96@gmail.com>
d17de17
to
fabdb56
Compare
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.
/lgtm
/assign @dchen1107
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dchen1107, deads2k, knight42, SergeyKanzhelev 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 |
Hi @knight42 1.25 Release Docs Shadow here. Does this enhancement work planned for 1.25 require any new docs or modification to existing docs? |
Signed-off-by: Jian Zeng anonymousknight96@gmail.com
Rendered