jiebi/CodeConvo huggingface dataset:
[X] test approval issue : [X] test pr : [x] two weeks soak end date : 11 Sept 2023 [x] test promotion pr : [x] remove endpoint from According to following APIsnoop query, there are two PersistentVolume and three PersistentVolumeClaim endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 13 endpoints. The e2e logs for this test are listed below. This query shows the following PV and PVC endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 13 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/cc
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/kind bug Right now we do not validate PV updates so admin can update at any time. Kubernetes has no facility to reflect this update - it won't magically re-mount an existing volume to e.g. a different NFS server. IMO the PersistentVolumeSource to be read-only and set to stone once created.
/assign
I think it is a good idea to make the VolumeSource read-only but I am afraid ship has sailed in v1 and existing code/tooling that relies on the ability to modify PVs will break as a result of this change.
- do you have any advice on how we should proceed on fixing this issue?
What happened: The vresion of the hostpathplugin specified in the kubernetes e2e tests had a bug in cloning causing storageclass compare checks to always fail. As a result e2e tests could not pass for cloning in kubernetes. What you expected to happen: The version referencedin e2e tests should have a working hostpathplugin image to enable e2e testing of clone functinoality. How to reproduce it (as minimally and precisely as possible): Attempt to run the e2e cloning test: without modifying the hostpathplugin image version, test will fail due to storageClass mismatch even when set properly in the test. Anything else we need to know?: Fix in hostpathplugin is available in hostpathplugin:v1.2.0-rc4 There's also a required update to the provisioner side-car which has been submitted here:
/sig storage /assign
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --Start the scheduler with a scheduler config file which has a custom configuration for a specific plugin, the scheduler will fail to start and throw below exception, kube- error message, custom plugin config should take precedence over default plugin config. start a scheduler with a config file. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig scheduling /assign
Does disabling the plugin and re-enabling the same plugin with a different weight work as a workaround?
This is WAI. You have to explicitly disable the default configuration.
I think so.
I not sure I agree with this, particularly, for someone who doesn't know details of code IMPL, e.g. an operator, Why bother to disable the plugin first and then re-enable the same plugin? there is no pointer to show they are different in a config file, as a developer, we know the reason behind the scenes, can we assume operator also know what that means to define a schedule config? By disabling the plugin and re-enable it means the operator has the knowledge this plugin is a default enabled plugin, should the operator check the source code to confirm this plugin's configuration? When this happens, given a different config for a specific plugin, should this deserve a corruption? I think scheduler should more robust to tolerate this.
We can improve the docs to include the default plugins. It's better for the API to be more predictable (always do the same thing). One thing to think about is order: if we do what your PR proposes, we are altering the order in which plugins are run, not just modifying the "weight" of the plugin.
I'm leaning towards closing this ?
It's the key point I'm concerned about: commented here So let me ask a question: for a given input like: What's the expected output? {DefaultPlugin1, 1}, {DefaultPlugin2, 200}, {DefaultPlugin3, 3}, OR {DefaultPlugin1, 1}, {DefaultPlugin3, 3}, {DefaultPlugin2, 200}
Today, it is 2.
So in other words, if a user wants to customize a plugin's weight and keep its order, the only way is to use and give a full list of plugins? If so, that's not a good UX IMO.
Well, order doesn't matter for Score, so not really a problem.
All right, so the only case users could disable PluginXYZ while also enabling PluginXYZ is Score plugins, I'm fine with the order issue. Back to this issue, my 2 cents is to change the semantics of to a more enforced manner (proposed in this issue) in a new API version - v1beta2 or GA. As IMO it's a real UX improvement. WDYT?
I'm not convinced it's a UX improvement. If the user "enables" a filter plugin that was a default (say, by mistake), then its order changes. At least first disabling the plugin makes it more explicit. cc who has been working on decisions based on CC version
I guess it depends on the implementation. What is the full proposal?
/remove-kind bug /kind feature
That's a fair point, esp. if we adjust default plugins from version to version. I think a good UX is to throw an error/warning to indicate that a default Filter plugin is being re-enabled - this's useful no matter which semantic employes.
I'd like to: keep current logic to warn users that "PluginXYZ" is already registered (by default), if it's a non-Score plugin apply the "overridden" semantics to directive, for Score plugins only btw: let's get a consensus first and better adopt it in new CC version.
I propose (only for new version): Fail when plugin is already registered in the custom configuration, and only warning if the plugin was already part of defaults. Override any weight, preserving order I think that keeps everything consistent.
I think this is what the last iteration of the PR is doing, but I only skimmed through it.
SGTM. To confirm, by "Fail when plugin is already registered in the custom configuration", this's only possible when users implement an out-of-tree plugin with a name identical to a default one, right?
I'm just referring to failing when the user repeats the same value twice. I think we can't prevent what you say.
This might be the reason why the order of the plugins should be reserved.
Unless it's score plugin like this issue, I don't know if there is any point to enable the default plugin in a config file. I think there is no need to distinguish score plugin with others, this will make the life easier, correct me?
Yeah, overall, is following this ideas, except that PR doesn't handle the repeated configuration, because if there is repeated value after the default plugin is overridden, it will hit the error below,
thanks for those valuable suggestion! So, we are still with beta1, and you suggest we can make some change in the new version, beta2? Is there any plan when this could happen? v1.22?
You are correct, there is no point, but it's good to have consistency. If it's allowed for Score, it should be allowed for other extension points. I agree Yes, that is the plan. It was 1.21, but we fall behind due to newer plans for deprecating plugins
let's say there are 3 default non-Score plugins A, B and C (in that order). I want to move B to the end of the list but I want to custom enable C too (for whatever reason; since we want to consistent with score plugins, let's allow this for other extension points too as said). if a non-Score plugin is custom disabled AND enabled, we should move it to the end of the list but if it's simply just enabled, then we should preserve order. if it's a score plugin, disabling and re-enabling has the same semantics as just simply enabling; they both will only change the weight. (idk if this has already been proposed; if it has been, consider this a vote of support :))
Are you saying that "disabled and enabled" should be treated the same as just "enabled"? That is, always move to the end of the list?
No, just "enabled" would NOT move things to the end of the list (it will preserve order), but "disabled and enabled" would move to the end of the list.
ok, that sounds good
Another problem here is if we don't want to overridden anything but just config a plugin which is accidently a default plugin, something like below, scheduler will fail as well, I think we need to De-dup here instead of just a warning here. I guess this PR should already cover this, I will go back to check it again, at least one more testcase is needed to cover this case. keep current logic to warn users that "PluginXYZ" is already registered (by default), if it's a non-Score plugin
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/lifecycle stale let me revive the PR later.
/remove-lifecycle stale
Hello and I were fuzzing the k8s (via ) and found out following bug. Getting logs from unicode logpath via API causes internal server error. The API endpoint is . Response with non-500 HTTP status code We were fuzzing k8s locally via minikube. minukube ca certificates k8s IP address the IP to as access token and export it as request Kubernetes version (use ):Cloud provider or hardware configuration: minikube with virtual-box driver OS (e.g: ): Ubuntu 18.04.5 LTS (bionic) Kernel (e.g. ): Linux pine 4.15.0-140-generic -Ubuntu SMP Fri Mar 19 14:12:35 UTC 2021 x8664 x8664 x86_64 GNU/Linux Install tools: downloaded precompiled binary minikube version: v1.19.0 (commit: )
/sig api-machinery
/assign I will look into it.
thank you , please keep us posted! /triage accepted
For clarity are you saying that the fuzzed URL is valid or invalid UTF-8 (URL-encoded)?
It's valid UTF-8
Actually, according to my test,this bug comes from http.ServeFile which replies to the request with the contents of the named file or directory. When giving too long(On Linux: The maximum length for a file name is 255 bytes. The maximum combined length of both the file name and path name is 4096 bytes.) filename or pathname to http.ServeFile,it will return code 500(file name too long) rather than 404(no such file or directory). And when filename is not that long, unicode path work correctly too. Here is my simple test below: And since /logs is the only place use http.ServeFile, there is no other api has the same problem. ! So I will add a length check before calling http.ServeFile to solve this. Does that sound good to you?
Maybe 400 - bad request would be more suitable response code. But I'm not a maintainer so it's not up to me to decide.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with .
Send feedback to sig-contributor-experience at . /lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Reopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /close [1]:
Closing this issue. <detailsIn response to : The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closedReopen this issue or PR with Mark this issue or PR as fresh with Offer to help out with [Issue Triage][1] Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Scenario: Expected results: pod would not be created as [0] is invalid Actual results: pod is created. Turns out we are not doing any validation of envFrom in container spec today.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
I don't know that we can tighten without failing pods.
The validation code exists, but there was no wiring done from validateContainers.
Pods fail on kubelet already. So those pods were not doing much already. We had a BZ on this.
Fail how - fail to even start, or fail to get the input?
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The local-volume bootstrapper/provisioner configuration format changed in kubernetes-incubator/external-storage, and its related e2e tests will fail when the provisioner & bootstrapper images are updated to v2.0.0. What you expected to happen: I'd expect the e2e tests to continue to work properly with the new version of the provisioner and boostrapper. How to reproduce it (as minimally and precisely as possible): Update local-volume provisioner and boostrapper images to v2.0.0, and then the provisioner e2e test will fail.
/sig storage
/assign
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: I wrote a test creating multiple isomorphic Events with an "". and stumbled upon a data race. The data race happens in the function. It seems that the Event Series field can be read and written at the same time by two different goroutines. . This seems to happen in only one scenario: (1) a singleton Event is created (2) an isomorphic Event is created (1) lock addition to cache (2) wait for the lock to be released (1) unlock (2) lock + the Series (1) the freshly created Series (1) singleton Event is now considered as a series That being said, this seems to lead to some data inconsistencies as the singleton Event would be created with an unexpected Series. <details<summaryData race</summary|================== WARNING: DATA RACE Write at 0x00c0001237a0 by goroutine 23: (eventBroadcasterImpl).recordToSink.func1.1() +0x536 (eventBroadcasterImpl).recordToSink.func1() +0x84 Previous read at 0x00c0001237a0 by goroutine 24: (Event).DeepCopyInto() +0x64 (Event).DeepCopy() +0x56 (Event).DeepCopyObject() +0x33 () +0xe8 (CreateActionImpl).DeepCopy() <autogenerated:1 +0xb7 (Fake).Invokes() +0x103 (FakeEvents).Create() +0x214 (EventSinkImpl).Create() +0x195 () +0x32c (eventBroadcasterImpl).attemptRecording() +0xe4 (eventBroadcasterImpl).recordToSink.func1() +0x9d Goroutine 23 (running) created at: (eventBroadcasterImpl).recordToSink() +0x159 (eventBroadcasterImpl).startRecordingEvents.func1() +0x75 (eventBroadcasterImpl).StartEventWatcher.func2() +0x91 Goroutine 24 (running) created at: (eventBroadcasterImpl).
recordToSink() +0x159 (eventBroadcasterImpl).startRecordingEvents.func1() +0x75 (eventBroadcasterImpl).StartEventWatcher.func2() +0x91 |================== |================== WARNING: DATA RACE Read at 0x00c0001236f0 by goroutine 23: (Event).DeepCopyInto() +0x64 (Event).DeepCopy() +0x72 () +0x4d () +0x98 (eventBroadcasterImpl).attemptRecording() +0xe4 (eventBroadcasterImpl).recordToSink.func1() +0x9d Previous write at 0x00c0001236f0 by goroutine 24: () +0x2e4 (eventBroadcasterImpl).attemptRecording() +0xe4 (eventBroadcasterImpl).recordToSink.func1() +0x9d Goroutine 23 (running) created at: (eventBroadcasterImpl).recordToSink() +0x159 (eventBroadcasterImpl).startRecordingEvents.func1() +0x75 (eventBroadcasterImpl).StartEventWatcher.func2() +0x91 Goroutine 24 (running) created at: (eventBroadcasterImpl).recordToSink() +0x159 (eventBroadcasterImpl).startRecordingEvents.func1() +0x75 (*eventBroadcasterImpl).StartEventWatcher.func2() +0x91 |================== </detailsWhat you expected to happen: No data race. How to reproduce it (as minimally and precisely as possible): You can run the following code snippet alongside any data race detector. I personally used . Anything else we need to know?: Environment: v0.25.0
/sig api-machinery
/assign Would you mind taking a look to this one? thanks!
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-contributor-experience at . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
We might also want to look into that again for /reopen /assign /unassign
/remove-lifecycle rotten
Reopened this issue. <detailsIn response to : We might also want to look into that again for /unassign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/cc
/cc
I was able to reproduce this issue with client-go v0.25.0. I updated the reproducer to be compatible with the latest version of the client and attached the data race trace.
are you gong to submit a fix for this one? thanks. /triage accepted
Yes, I am planning to submit a fix for this issue.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
A PR is out to fix this issue: /remove-lifecycle stale
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: 's memory usage is increasing over time. When more pods are run, it increases even more. What you expected to happen: it should not keep increasing How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.0 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: !
/sig windows /sig azure
/assign
<!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) Increase the log level of info logs to "v=2" when the scheduler or a node from its cache. 2) Increase the log level of info logs to "v=2" when the scheduler can't schedule a pod , , and add a log message for 2) report memory/cpu status of . Why is this needed: With cluster autoscaler now being used in production by some vendors, we want to have more visibility to events that could be related to the auto scaler to help debug customer issues. /sig scheduling /priority important-soon /assign
GitHub didn't allow me to assign the following users: congliu01. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : <!-- Please only use this template for submitting enhancement requests --1) Increase the log level of info logs to "v=2" when the scheduler or a node from its cache. 2) report memory/cpu status of . Why is this needed: With cluster autoscaler now being used in production by some vendors, we want to have more visibility to events that could be related to the auto scaler to help debug customer issues. /priority important-soon /assign </details
will consider this assigned to you.
/assign