jiebi/CodeConvo huggingface dataset:
Change:
myKubelet := kubelet.NewIntegrationTestKubelet(machineList[0], &fakeDocker1) go util.Forever(func() { myKubelet.Run(cfg1.Updates()) }, 0) go util.Forever(func() { <del> kubelet.ListenAndServeKubeletServer(myKubelet, cfg1.Channel("http"), http.DefaultServeMux, "localhost", 10250) </del> <ins> kubelet.ListenAndServeKubeletServer(myKubelet, cfg1.Channel("http"), "localhost", 10250) </ins> }, 0) // Kubelet (machine)

Discussion:
The Kubelet REST end-point has turned into a complicated switch-case code block that is harder to maintain overtime. The Kubelet should move to a http.ServeMux pattern and register handler functions to a pattern.
I am working on a PR to submit in next couple of days that will make this change, so feel free to assign to me if possible.
Tagging because I asked for this in one of his PRs
This one is also under my radar. If no one had time, feel free to assign it to me too.
I have a branch in progress. Feel free to offer feedback on it when I submit. Sent from my iPhone
Change:
// Make a placeholder channel to use when there are no items in our list never := make(<-chan time.Time) <ins> // Make a timer that expires when the item at the head of the waiting queue is ready var nextReadyAtTimer clock.Timer </ins> waitingForQueue := &waitForPriorityQueue{} heap.Init(waitingForQueue)

Discussion:
Hi, We are experiencing a memory leak in our operator and it seems to be caused by some Timers: ! See here the original issue: After some investigations I found out that the can create a lot of timers (at least ) if the queue is not empty : The problem here is that if the event in the queue is to expire in a "far" future the previous timers will pile up and the memory will be reclaimed too late. Could someone confirm this scenario ? A fix would be to create some with and close them when they are not needed (e.g. is called) or superseded by a most recent one. Happy to discuss the issue and contribute if needed.
thanks for the report, moved to the main repo for better visibility /sig api-machinery
yes, using NewTimer would be better here
thanks for your feedback, could you assign me to this issue ? I will try to provide a fix.
Thanks, I have opened a PR:
Change:
{ Name:  "webserver", Image: "kubernetes/nettest:1.1", <del> Command: []string{ </del> <ins> Args: []string{ </ins> "-service=" + name, fmt.Sprintf("-peers=%d", peers), "-namespace=" + ns},

Discussion:
Forked from downward, this test has been failing since go/k8s-test/kubernetes-e2e-gce/4042, which lines up well with . Assigning to to fix, though a revert may be in order soon (we've had too much noise).
The issue is that I didn't change the networking e2e to set 'Args' instead of 'Command'.
Clients shouldn't be using the internal representation.
hmmmm ... is this really fixed? not working for me atm.
What behaviors are you seeing?
This is a recent run of our Jenkins server:
Re-closing (that was a success I pasted).
This might be the test failure you mentioned over hangout. The detail information can be found at: The issue is fixed this morning. Thanks!
Change:
nodes := makeLabeledNodeList(test.nodes) snapshot := nodeinfosnapshot.NewSnapshot(nodeinfosnapshot.CreateNodeInfoMap(test.pods, nodes)) serviceLister := fakelisters.ServiceLister(test.services) <del> priorityMapFunction, priorityReduceFunction := priorities.NewServiceAntiAffinityPriority(snapshot.Pods(), serviceLister, test.labels) </del> p := &ServiceAffinity{ <del> sharedLister:           snapshot, serviceLister:          serviceLister, priorityMapFunction:    priorityMapFunction, priorityReduceFunction: priorityReduceFunction, </del> <ins> sharedLister:  snapshot, serviceLister: serviceLister, args: Args{ AntiAffinityLabelsPreference: test.labels, }, </ins> } metaDataProducer := priorities.NewMetadataFactory( fakelisters.ServiceLister(test.services),

Discussion:
/sig scheduling /priority important-soon See as an example. /assign
/unassign /help
/assign
/remove-help
Change:
framework.DeletePodWithWait(f, f.ClientSet, pod) }() By("Checking for subpath error in container status") <del> err = waitForPodSubpathError(f, pod) </del> <ins> err = waitForPodSubpathError(f, pod, allowContainerTerminationError) </ins> Expect(err).NotTo(HaveOccurred(), "while waiting for subpath failure") }

Discussion:
<!-- 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!--What happened: The read only sig-storage tests validate that Pods can come up when readOnly is set. But it doesn't actually validate that the container cannot write to the volume. What you expected to happen: Tests should validate that the container cannot write to readonly volumes. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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
can this issue be closed after your last PR or is there more to work on? If yes I'd like to know what's left because I'm looking for something to work on
I think we should actually reinstate the test case I removed and enhance it to handle the two scenarios I mentioned. It would also be good to see if we have other readOnly test cases that could be enhanced as well
Thanks ! I have a few questions: 1) how do I run the tests in locally? and 2) how can I assert writing to volume has failed? Thank you in advance!!
Change:
"strings" "testing" <ins> "github.com/google/go-cmp/cmp" </ins> "github.com/stretchr/testify/assert" corev1 "k8s.io/api/core/v1" <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/diff"

Discussion:
<!-- 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 --my mutating webhook calculates a hash of the , allows reinvocation; no side effects my validating webhook validates the hash of the and fails because the has changed webhook auditing indicates that my webhooks are the only ones processing the upon serializing the spec to JSON for both the mutator and validator, the only change is related to the "kube-api-access-xyz" projected volume, managed by a built-in k8s admission plugin the aforementioned plugin does not appear to mutate the reinvocation context, even through it may mutate a pod (robbing other mutators of the chance to observe the change): it appears that both my hooks see the injected volume, but the validation hook sees the injected SA volume with a "defaultMode" field set, and my mutation hook does NOT see this field set my validation hook should calculate the same hash mutating, validating webhooks are implemented atop controller-runtime v0.8.3, pod objects are being decoded into targets Kubernetes version (use ): 1.21.3 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:
/sig api-machinery
cc
interesting... defaults are applied when going from versioned → internal server decodes v1 Pod request → applies defaults → converts to internal Pod -in admission control operates on the internal Pod service account admission injects the kube-api-access volume admission is called internal Pod → converts to v1 Pod → serializes → sends to mutating webhook mutating webhook returns patch patch is applied to v1 Pod JSON resulting v1 Pod JSON is decoded → defaults applied (defaultMode is set on the api-token volume here) → converted to internal Pod webhook admission is called internal Pod → converts to v1 Pod → serializes → sends to validating webhook That means if any built-in admission plugin sets up data that would be modified by applying defaulting to the pod, the data sent to mutating webhooks will be missing those applied defaults until the first mutating webhook that returns a patch that changes the object
Possible solutions: defaults are applied to the internal → versioned object before invoking webhooks built-in admission always populates data matching default values for unset fields
As an aside, I'm not sure what you're using the hashing for, but be aware that hashing is fragile in the presence of defaults and new fields over time. A hash you add to a pod spec in one release might not match a hash computed in a different release, or with different admission in place.
/triage accepted /assign /priority backlog
Change:
* [kubectl config](kubectl_config.md)	 - config modifies kubeconfig files <del> ###### Auto generated by spf13/cobra on 8-Dec-2015 </del> <ins> ###### Auto generated by spf13/cobra on 8-Jan-2016 </ins> <!-- BEGIN MUNGE: GENERATED_ANALYTICS --> [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/docs/user-guide/kubectl/kubectl_config_set-credentials.md?pixel)]()

Discussion:
It acts like a boolean flag but requires an argument, unlike boolean flag is pretty much every environment. We need to find a better way to express the things that this is expressing. Maybe a add a tristate to the pflag lib that behaves the same way but doesn't demand an argument?
cc
The handles "true", "false", "unset" and has a default value. I seem to recall you were looking at changing it, but we needed to preserve the value. The complain here is that you have to do instead of just . /cc
fixing is really easy....
Change:
// Duplicated, should be ignored. port("foo", v1.ProtocolUDP, 888, 8888, ""), // Duplicated, should be ignored. <del> port("", v1.ProtocolTCP, 80, 8888, ""), </del> <ins> port("", v1.ProtocolTCP, 80, 8888, "127.0.0.1"), // Duplicated with different address family, shouldn't be ignored port("", v1.ProtocolTCP, 80, 8080, "::"), // No address family specified port("", v1.ProtocolTCP, 1234, 5678, ""), </ins> }, }, []PortMapping{ <del> portMapping("fooContainer-TCP:80", v1.ProtocolTCP, 80, 8080, "127.0.0.1"), portMapping("fooContainer-TCP:443", v1.ProtocolTCP, 443, 4343, "192.168.0.1"), </del> <ins> portMapping("fooContainer-v4-TCP:80", v1.ProtocolTCP, 80, 8080, "127.0.0.1"), portMapping("fooContainer-v4-TCP:443", v1.ProtocolTCP, 443, 4343, "192.168.0.1"), </ins> portMapping("fooContainer-foo", v1.ProtocolUDP, 555, 5555, ""), <ins> portMapping("fooContainer-v6-TCP:80", v1.ProtocolTCP, 80, 8080, "::"), portMapping("fooContainer-any-TCP:1234", v1.ProtocolTCP, 1234, 5678, ""), </ins> }, }, }

Discussion:
What happened: I tried to create a deployment with duplicate containerPorts with hostIPs of two different address families. Only the first mapping was provided as input into my CNI plugin chain. Also, a log message from kubelet warning about a duplicate containerPort was created. What you expected to happen: Both mappings to be provided as input into my CNI plugins. No log messages should be created. How to reproduce it (as minimally and precisely as possible): Create this deployment: Then grab kubelet logs on the host e.g: Anything else we need to know?: This issue here provides some context as to how I ran into this issue: Environment: Kubernetes version (use ): v1.15.1 Cloud provider or hardware configuration: DigitalOcean, custom setup OS (e.g: ):Kernel (e.g. ):Install tools: None Network plugin and version (if this is a network-related bug): Cilium v1.6.0 and Portmap v0.8.2 Others: N/A I've already identified the problem and will submit a PR which fixes this shortly. /sig network
is this dual-stack only? if so, does the fix for this need to target 1.16?
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
This applies to dual-stack only yes. I don't know if it should target 1.16, personally I'd like to get this out so I don't have to run a forked version of kubelet.
/assign
I would agree that this should hit v1.16 if possible.
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
Change:
<ins> /* Copyright 2023 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package runtime import ( "context" v1 "k8s.io/api/core/v1" compbasemetrics "k8s.io/component-base/metrics" "k8s.io/kubernetes/pkg/scheduler/framework" ) type instrumentedFilterPlugin struct { framework.FilterPlugin metric compbasemetrics.CounterMetric } var _ framework.FilterPlugin = &instrumentedFilterPlugin{} func (p *instrumentedFilterPlugin) Filter(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeInfo *framework.NodeInfo) *framework.Status { p.metric.Inc() return p.FilterPlugin.Filter(ctx, state, pod, nodeInfo) } type instrumentedPreFilterPlugin struct { framework.PreFilterPlugin metric compbasemetrics.CounterMetric } var _ framework.PreFilterPlugin = &instrumentedPreFilterPlugin{} func (p *instrumentedPreFilterPlugin) PreFilter(ctx context.Context, state *framework.CycleState, pod *v1.Pod) (*framework.PreFilterResult, *framework.Status) { result, status := p.PreFilterPlugin.PreFilter(ctx, state, pod) if !status.IsSkip() { p.metric.Inc() } return result, status } </ins>

Discussion:
We observed degradation in scheduling throughput, putting it under 100 pods/s. Respective pprof of kube-scheduler points it to ! /sig scheduling /kind regression 100 pods/node n/a No response <details</details<details</details<details</details<details</details<details</details<details</details
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
/cc
/sig scalability
Thanks for noticing it /assign
just to confirm this bug is present only in 1.27 ( introduced with pluginevaluationtotal metric) , isn't it ?
Exactly, 1.27+ (so the current master as well) to be specific.
Change:
gcePDDetachPollTime = 10 * time.Second nodeStatusTimeout   = 1 * time.Minute nodeStatusPollTime  = 1 * time.Second <ins> gcePDRetryTimeout   = 5 * time.Minute gcePDRetryPollTime  = 5 * time.Second </ins> ) var _ = framework.KubeDescribe("Pod Disks", func() {

Discussion:
For: "Pod Disks should schedule a pod w/ a RW PD, remove it, then schedule it on another host" "Pod Disks should schedule a pod w/ a readonly PD on two hosts, then remove both." (this is not happening on v1.3 master with v1.1 nodes, nor with v1.2 tests against a v1.3 cluster) View logs and artifacts at
Mind taking a look? You should be able to repro by turning up a v1.3 cluster and running v1.1 tests against it.
for your queue
I found the cause of the test failure. The following are the main steps in the test host0Pod, and wait for it running a file to the host0Pod, and then delete it host1Pod, and waiting for it running the file from host1Pod, and then delete it disk with deletePDWithRetry() function, which has 3 minutes timeout defer() function, clean up test environment, and also run deletePDWithRetry() again just in case The problem arises from step 5. In the above test, deletePDWithRetry tried to delete PD every 5 second, but failed in 3 minutes. After it exits retry loop, it failed for the expectNoError(err, "Error deleting PD") in this function. Although it deleted the PD successfully right after this during the clean up phase (step 6). So the main issue for this test failure is the timeout is a little bit short. To fix it issue, we can either increase the timeout, or not fail when calling deletePDWithRetry for the first time. We can fail it if it cannot delete it after calling deletePDWIthRetry second time in step 6. The following is the retry loop and error code in the deletePDWIthRetry(). In current 1.3 version, we only call deletePDWithRetry once in defer() function during clean up. I think to be safe we should increase timeout to 5 minutes, and set it in the constance instead of coding it directly inside of the function.
So two options to fix this: port test fixes from main branch to the 1.1 branch to make the test more robust against delays. for to be merged, which will decrease the time it takes for a volume to be detached and therefore how long it takes to be deleted.
Change:
#                 collisions here? "${GCLOUD}" compute firewall-rules create  "${MINION_TAG}-${USER}-http-alt"  <del> --allow tcp:80 tcp:8080  </del> <ins> --allow tcp:80,tcp:8080  </ins> --project "${PROJECT}"  --target-tags "${MINION_TAG}"  --network="${NETWORK}"

Discussion:
This happens over and over. Scary messages. WARNING: Lists should be separated by commas, try "--allow=tcp,udp,icmp,esp,ah,sctp". If you intend to use udp, icmp, esp, ah, sctp for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--scopes=storage-ro,compute-rw". If you intend to use compute-rw for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--metadata-from-file=startup-script=/usr/local/google/home/thockin/src/kubernetes/hack/e2e-internal/../../cluster/../cluster/gce/../../cluster/../cluster/gce/configure-,kube-env=/tmp/kubernetes.MURmzX/master-kube-". If you intend to use kube-env=/tmp/kubernetes.MURmzX/master-kube- for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--disk=name=e2e-test-thockin-master-pd,device-name=master-pd,mode=rw,boot=no,auto-delete=no". If you intend to use device-name=master-pd, mode=rw, boot=no, auto-delete=no for positional arguments, put them before the flag.
That's a new one. gcloud started getting a little more anal here. Exciting. cc
They changed list argument syntax a while back, but the warnings are new. Time to update startup scripts I guess.
Change:
} for _, pv := range allPVs.Items { if pv.Spec.StorageClassName == scName { <ins> pv := pv </ins> remainingPVs = append(remainingPVs, &pv) } }

Discussion:
At , within the loop , variable is shared by all the loop iterations, as described in the Go specification (). All instances of &pv within the loop may refer to the last tem updated by the loop. As a consequence, may hold multiple instances of the same item. Later on these remaining PVs are deleted, so it is possible that the same is deleted multiple times: More information on the bug can be found at A fix is to avoid reusing the shared variable node: Found by #deepgo.
/triage accepted /area e2e-test-framework
Thanks for pointing out, makes complete sense. I'm happy to fix it. /assign
/sig testing

At , within the loop , variable is shared by all the loop iterations, as described in the Go specification (). All instances of &node within the loop may refer to the last node item updated by the loop. As a consequence, may hold multiple instances of the same node. Note that the following unit test checks only the number of nodes rather than the nodes themselves (otherwise the bug may be revealed): More information on the bug can be found at A fixe is to avoid reusing the shared variable : Found by #deepgo.
/triage accepted /area e2e-test-framework /sig testing
Thanks for pointing out, makes complete sense. I'm happy to fix it. /assign
Change:
return fmt.Errorf("failed to create client pod %q: %v", clientPod.Name, err) } defer func() { <del> // note the test dir will be removed when the kubelet unmounts it </del> <ins> deleteFile(clientPod, ddInput) </ins> By(fmt.Sprintf("deleting client pod %q...", clientPod.Name)) e := framework.DeletePodWithWait(f, cs, clientPod) if e != nil {

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: [sig-storage] In-tree Volumes [Driver: hostPath] [Testpattern: Inline-volume (default fs)] volumeIO should write files of various sizes, verify size, validate content [Slow] Since when has it been failing: 11/13 Testgrid link: https://k8s- Reason for failure: Anything else we need to know: This is consistently failing in 1.13 branch and is release blocking. <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test /sig storage /priority critical-urgent /milestone v1.13 /assign /cc
The test case is failing because it wrote 2MB instead of the expected 1MB. It's also very odd that the test is failing in soak, but passing in regular CI suites.
There's a few problems: .GetVolumeSource returns "/tmp" for everything. This means all tests will share the same directory. This should be probably use some unique directory instead volume IO test generates a unique mountPath directory, however that doesn't mean a unique directory is actually created on the host. Ie, a mountPath of "/a/b/c" on a hostpath volume at "/tmp" doesn't mean directory "/tmp/a/b/c" is created. io test file name is not unique seems like the IO test is not cleaning up the files it creates, so the files are getting reused on subsequent tests due to the non-unique naming issues.
The other thing I can't explain is why it's failing only now
Fix is here:
As per discussion in 1.13 burndown this morning, this is a test job issue and its not release blocking at this point. So we can take this fix in 1.14 as opposed now during code freeze let us know if you feel otherwise
/milestone v1.14 /priority important-soon
/remove-priority critical-urgent