-
Notifications
You must be signed in to change notification settings - Fork 40.1k
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
API: add a new Stream
field to PodLogOptions
#127360
API: add a new Stream
field to PodLogOptions
#127360
Conversation
Skipping CI for Draft Pull Request. |
c1b5916
to
dd48818
Compare
/test all |
@knight42: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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-sigs/prow repository. I understand the commands that are listed 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.
/lgtm
/approve
LGTM label has been added. Git tree hash: 663b4ced2a837955877de6722163df121ff455ec
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: knight42, SergeyKanzhelev, thockin 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 |
/unhold |
Finally... my first KEP implementation PR gets merged! 🎉 Thank you all for your patience and professional advice! |
Congratulations. This was a hard one because URL params are not as well documented or exercised as other paths. |
Nice job @knight42! I see that we had a kubectl PR up for this but that seems to not be ready. Is this a blocker for this feature? I guess one can use crictl or other ways to test this feature but we may want to target the kubectl feature for 1.33? |
I am working on it. This might be a blocker, as users cannot request a specific stream seamlessly without a updated kubectl. While they can use
Actually, crictl needs to be updated as well to set the newly introduced
I am okay with that. |
If you want to aim for 1.32, you will need to request an extension for that PR. Since this is alpha, I don't think we need everything but we should maybe consider that a blocker for beta. @thockin WDYT? |
Without a CLI we will not get any meaningful feedback, I think
…On Fri, Nov 8, 2024 at 8:12 AM Kevin Hannon ***@***.***> wrote:
If you want to aim for 1.32, you will need an extension.
Since this is alpha, I don't think we need everything but we should maybe
consider that a blocker for beta. @thockin <https://github.com/thockin>
WDYT?
—
Reply to this email directly, view it on GitHub
<#127360 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKWAVA6IL4RASKUNU3GDVTZ7TPHLAVCNFSM6AAAAABOG6CLG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRVGE2DOMZSGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
True but we also don't get meaningful feedback for an alpha feature.. |
So our option right now is:
Or we aim to get kubectl in and if not, we revert this feature since there is not really a possible way to test this at the moment? Given that it is alpha, I think our plan is fine but it does mean that @knight42 has a bit more work in 1.33 to get this ready for beta. |
Why I am pressing this: kubernetes/enhancements#3288 (comment). I'm trying to understand what we should do with this feature for 1.32. |
I wonder if anybody who can review CLI is around to tell how close it is. It looks complete for me - enough to ask for an exception. |
I can update |
I'm not arguing to revert this, but I am arguing to try to get the CLI part of this in (and in future to not merge half of a feature) |
Well it looks like there is something up with this feature anyway. We may have to revert anyway. |
it looks like this validation code is requiring the new Stream option be populated if the feature is enabled:
isn't that breaking? elsewhere, we write:
|
if !utilfeature.DefaultFeatureGate.Enabled(features.PodLogsQuerySplitStreams) { | ||
logOpts.Stream = nil | ||
} | ||
if errs := validation.ValidatePodLogOptions(logOpts, utilfeature.DefaultFeatureGate.Enabled(features.PodLogsQuerySplitStreams)); len(errs) > 0 { |
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 seems to break the tests.
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.
not just the tests, I think it breaks existing pod log API clients when the feature is enabled
I opened up #128712. We can also revert this if that is the preferred method. |
What type of PR is this?
/kind api-change
/kind feature
What this PR does / why we need it:
Supersede #110794
This PR adds the feature gate and API for kubernetes/enhancements#3288 as well as validation rules to prevent inconsistent values. Only the changes about API, kube-apiserver and kubelet is included in this PR.
I plan to update the kubectl after this PR is merged in case the volume of this PR is too large.
Special notes for your reviewer:
We have decided not to support the combination of a specific
Stream
andTailLines
. Please refer to kubernetes/enhancements#4879 for rationale.Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: