jiebi/CodeConvo huggingface dataset:
Change:
framework.ConformanceIt("should support (non-root,0777,default) [LinuxOnly] [NodeConformance]", func() { doTest0777(f, testImageNonRootUid, v1.StorageMediumDefault) }) <ins> It("pod should support shared volumes between containers", func() { var ( volumeName                 = "shared-data" busyBoxMainVolumeMountPath = "/usr/share/volumeshare" busyBoxSubVolumeMountPath  = "/pod-data" busyBoxMainVolumeFilePath  = fmt.Sprintf("%s/shareddata.txt", busyBoxMainVolumeMountPath) busyBoxSubVolumeFilePath   = fmt.Sprintf("%s/shareddata.txt", busyBoxSubVolumeMountPath) message                    = "Hello from the busy-box sub-container" busyBoxMainContainerName   = "busybox-main-container" busyBoxSubContainerName    = "busybox-sub-container" resultString               = "" ) pod := &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name: "pod-sharedvolume-" + string(uuid.NewUUID()), }, Spec: v1.PodSpec{ Volumes: []v1.Volume{ { Name: volumeName, VolumeSource: v1.VolumeSource{ EmptyDir: new(v1.EmptyDirVolumeSource), }, }, }, Containers: []v1.Container{ { Name:    busyBoxMainContainerName, Image:   imageutils.GetE2EImage(imageutils.BusyBox), Command: []string{"/bin/sh"}, Args:    []string{"-c", "sleep 10"}, VolumeMounts: []v1.VolumeMount{ { Name:      volumeName, MountPath: busyBoxMainVolumeMountPath, }, }, }, { Name:    busyBoxSubContainerName, Image:   imageutils.GetE2EImage(imageutils.BusyBox), Command: []string{"/bin/sh"}, Args:    []string{"-c", fmt.Sprintf("echo %s > %s", message, busyBoxSubVolumeFilePath)}, VolumeMounts: []v1.VolumeMount{ { Name:      volumeName, MountPath: busyBoxSubVolumeMountPath, }, }, }, }, RestartPolicy: v1.RestartPolicyNever, }, } var err error By("Creating Pod") pod = f.PodClient().CreateSync(pod) By("Waiting for the pod running") err = f.WaitForPodRunning(pod.Name) framework.ExpectNoError(err, "failed to deploy pod %s", pod.Name) By("Geting the pod") pod, err = f.PodClient().Get(pod.Name, metav1.GetOptions{}) framework.ExpectNoError(err, "failed to get pod %s", pod.Name) By("Reading file content from the nginx-container") resultString, err = framework.LookForStringInFile(f.Namespace.Name, pod.Name, busyBoxMainContainerName, busyBoxMainVolumeFilePath, message, 30*time.Second) framework.ExpectNoError(err, "failed to match expected string %s with %s", message, resultString) }) </ins> }) const (

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : This is a place holder to track Conformance Coverage on the Topic. This issue should remain open until all related work is accomplished in the k/k repo This issue will contain analysis of the coverage. Existing tests and additional tests requested with links to those issues/PR's Why is this needed: Conformance coverage for CSI, etc. /area conformance /assign /cc
/sig testing
Change:
RegistryPullQPS:             5, HairpinMode:                 kubeletconfig.PromiscuousBridge, NodeLeaseDurationSeconds:    1, <del> CPUCFSQuotaPeriod:           metav1.Duration{Duration: 100 * time.Millisecond}, </del> <ins> CPUCFSQuotaPeriod:           metav1.Duration{Duration: 25 * time.Millisecond}, FeatureGates: map[string]bool{ "CustomCPUCFSQuotaPeriod": true, }, </ins> } if allErrors := ValidateKubeletConfiguration(successCase1); allErrors != nil { t.Errorf("expect no errors, got %v", allErrors)

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 --See for more context. What happened: When you set and , you'd expect container cfs quota period to be . However, unless you also set in the feature flags, the quota value will be silently ignored. What you expected to happen: At least a warning be logged if the feature is not enabled but is set. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: 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:
/sig node /assign karan
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig node 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
Change:
} type BootstrapTokenAuthenticationOptions struct { <del> Allow bool </del> <ins> Enable bool </ins> } type KeystoneAuthenticationOptions struct {

Discussion:
/kind feature As part of , the flag on the API server should be renamed to something like . We'll leave deprecated (should it be a no-op or not?) for v1.8. Or we should consider adding an explicit flag to the API server in the same way we have  flag on controller-manager. Right now, it enables/disables most authn plugins implicitely based on other flags (often pointing to various files on disk; if you specified a path to that file, you also want to enable this authn module) What way do you prefer?
/assign
Rough plan: (1.8) Add (1.8) Make it an error to specify both and (so we don't have to decide on precedence) (1.8) Add a warning if is used. (1.9) Drop
is: Mark deprecated. cc Approve?
/reopen Re-opening because there's a little bit left to do in 1.9 (ready to go in ).
[MILESTONENOTIFIER] Milestone Labels Incomplete Action required: This issue requires label changes. If the required changes are not made within 6 days, the issue will be moved out of the v1.8 milestone. priority: Must specify exactly one of [, , ]. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Change:
predicateName                                    string podsOnNode                                       []*v1.Pod nodeCondition                                    []v1.NodeCondition <ins> nodeUnschedulable                                bool </ins> ds                                               *apps.DaemonSet wantToRun, shouldSchedule, shouldContinueRunning bool err                                              error

Discussion:
DaemonSet should not respect node's field. It's because cluster operators often want system components to be running and ready before workloads run on a given node. OTOH, DaemonSet does respect NoSchedule taints. This behavior is broken by , because DaemonSet share some predicates code with default scheduler.
/assign
Added this to 1.10 milestone, because it's a regression introduced in 1.10.
can you (or a SIG lead) add status/approved-for-milestone please? I'll add the priority. /priority important-soon
how is this use case satisfied by the daemonset controller creating pods and depending on the scheduler to assign them to nodes? having the scheduler ignore the unschedulable field seems nonsensical
I'd like get this as limitation for alpha feature; when upgrade to beta, I'd like to use taint to replace un-scheduable, so DaemonSet pod can tolerate it on-demand.
Escalating to critical-urgent, since we are now in Code Freeze. Please update daily with status, thanks! /priority critical-urgent /remove-priority important-soon
In short term, scheduler can check of pods and ignore bit of nodes for DS pods. Long term, when TaintNodesByCondition is stable, we should replace bit by taint and have DS controller add toleration for the taint when creating pods.
That doesn't seem proper. Making pods behave differently depending on the type of their creating object is very counterintuitive. That seems more reasonable. I'm less certain about auto- tolerations
- indeed there's some work currently to move from to a taint based behaviour, tracked by
Change:
return framework.NewStatus(framework.Error, err.Error()) } <del> if v1helper.TolerationsTolerateTaintsWithFilter(pod.Spec.Tolerations, taints, func(t *v1.Taint) bool { </del> <ins> filterPredicate := func(t *v1.Taint) bool { </ins> // PodToleratesNodeTaints is only interested in NoSchedule and NoExecute taints. return t.Effect == v1.TaintEffectNoSchedule || t.Effect == v1.TaintEffectNoExecute <del> }) { </del> <ins> } taint, isUntolerated := v1helper.FindMatchingUntoleratedTaint(taints, pod.Spec.Tolerations, filterPredicate) if !isUntolerated { </ins> return nil } <del> return framework.NewStatus(framework.UnschedulableAndUnresolvable, ErrReasonNotMatch) </del> <ins> errReason := fmt.Sprintf("node(s) had taint {%s: %s}, that the pod didn't tolerate", taint.Key, taint.Value) return framework.NewStatus(framework.UnschedulableAndUnresolvable, errReason) </ins> } // postFilterState computed at PostFilter and used at Score.

Discussion:
When trying to see why pods don't start using either kubectl get events or kubectl describe pod , the base message is not detailed enough. Warning FailedScheduling 5s (x4 over 65s) default-scheduler 0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate. What would you like to be : Details of the taint and details of what it didn't tolerate Why is this needed: To get much much better debug information by default when trying to understand why pods can't launch.
/sig cli
/sig scheduling /priority important-longterm
/cc
/remove-sig cli
Those labels are not set on the issue: <detailsIn response to : /remove-sig cli </details
/good-first-issue
/assign starizard
Can I get an idea of what this would involve? I might be able to put some work on it.
I assume is taking this already. The error message is produced in We probably also require changes in to get the name of the missing toleration.
/remove-help
Change:
set := index[indexValue] if set != nil { set.Delete(key) <ins> // If we don't delete the set when zero, indices with high cardinality // short lived resources can cause memory to increase over time from // unused empty sets. See `kubernetes/kubernetes/issues/84959`. if len(set) == 0 { delete(index, indexValue) } </ins> } } }

Discussion:
What happened: Consider this use case, a k8s cluster with many short lived name spaces with a high cardinality. (Think UUIDs). Over time, some of the indices contain string sets for each name space with no objects in the backing string sets; which are never reused. Leads to process memory increasing over time until the process exceeds available memory. Potentially causing issues as an api-server or controller is terminated by the operating system. What you expected to happen: Process memory does not increase unbounded as the number of unique items then deleted from a thread safe map, causing indices to hold on to zero length string sets for the key. This could be mitigated when an index's string set for a key is empty, that string set is removed from the index. How to reproduce it (as minimally and precisely as possible): Thanks to for this reproduction code: Anything else we need to know?: Can be mitigated with the following patch against master at : has a code path for creating sets that don't exist, so if a set is temporarily reduced to zero; it will be re-created as if it was the initial case where the set was never created. Here's an apiserver pprof heap base png from a clean start for a test case of ≈800k name space create/delete in kube v1.14.7: Note the increase in heap utilisation from base of and nodes in the hot path. Similar increases were observed in v1.13.11 and v1.15.5. Same as above, but with the suggested fix and ≈100k name space create/delete: Note lack of and nodes in the hot path. (Was not able to directly attach the images to this issue due to Something went really wrong, and we can't process that file.) Environment: Kubernetes version (use ): Issue reproduced in v1.13.11, v1.14.7, 1.15.5 directly by adding/deleting namespaces. Above mitigation directly tested against a v1.14.7 cluster.
/sig api-machinery
Edit: I found threadSafeMap.updateIndices() - was searching with misspelled func name.
I'm not sure I follow, but is still present -
Nah, my bad; didn't spell the method right originally in the text.

One option is to mark the time when set becomes empty: We can clean Index entry when certain period has passed since the set becomes empty.
I really don't think that solution is a viable and adds unneeded complexity. You would then need to have something running in the background to prune empty sets. The solution proposed in the original post is the most straight forward, when the set is empty - delete it. If something is then created that needs the set, it will be recreated when needed.
I think that is fine.
Change:
} } command := fmt.Sprintf("echo '%s' > '%s'; sync", contents, path) <del> // TODO(mauriciopoppe): remove this statement once we add `sync` to the test image, ref #101172 if e2epod.NodeOSDistroIs("windows") { command = fmt.Sprintf("echo '%s' > '%s';", contents, path) } </del> stdout, stderr, err := tk.kubectlExecWithRetry(tk.Namespace, podName, containerName, "--", "/bin/sh", "-c", command) if err != nil { e2elog.Logf("error running kubectl exec to write file: %vnstdout=%vnstderr=%v)", err, string(stdout), string(stderr))

Discussion:
We'd like to add to the windows nodes Discussed in , some storage e2e tests need the call to flush data to disk, this utility is not available in windows nodes or agnhost /sig storage /sig testing
/sig testing
/sig storage /kind flake
/sig windows
Does sync only need to be in Agnhost or also on the Windows node? I don't think there is any issue with adding to the agnhost for this tests. Has it been tested that it works? /cc in case you have thoughts
In the README of sync it says: Initially I thought it could be to agnhost however told me that Windows containers cannot run in privileged mode as of today. cc
Since we run the Windows Test containers as they should have full access to modify the host files if the host path is mapped in.
I downloaded the zip file and I checked that it has an EULA, do you know which sig would help with the license?
Hm, if the sysinternal is problematic, what about the GNU one? It seems to come from coreutils, which can easily be downloaded and extracted from. Hopefully, they are 64-bit binaries. Anyways, I think adding is a good idea, there are a few other non-conformance tests that are calling sync.
I believe that would be sig-contributor-experience. I thought we were using other sys-internal tools as well but it is a good idea to double check.
/triage accepted /assign
/remove-sig testing we don't own the nodes (?)
I've sent , which would add using that PR. Let us know if that satisfies your requirements, we could merge afterwards.
Thanks I guess we can merge the PR and I can run the storage e2e tests that need .
Change:
return err } if status == api.PodSucceeded || status == api.PodFailed { <del> return handleLog(c, pod.Namespace, pod.Name, &api.PodLogOptions{Container: pod.Spec.Containers[0].Name}, opts.Out) </del> <ins> return handleLog(c, pod.Namespace, pod.Name, &api.PodLogOptions{Container: opts.GetContainerName(pod)}, opts.Out) </ins> } opts.Client = c opts.PodName = pod.Name opts.Namespace = pod.Namespace <del> return opts.Run() </del> <ins> if err := opts.Run(); err != nil { fmt.Fprintf(opts.Out, "Error attaching, falling back to logs: %vn", err) return handleLog(c, pod.Namespace, pod.Name, &api.PodLogOptions{Container: opts.GetContainerName(pod)}, opts.Out) } return nil </ins> } func getRestartPolicy(cmd *cobra.Command, interactive bool) (api.RestartPolicy, error) {

Discussion:
runs foo and then waits for it to be ready or terminated. If the pod is terminated, it prints the log, and if it's not terminated, it attaches the output. However, it does not handle the case that the pod terminates between returning the ready status and attaching, as can be the case in the : Options to fix this: Fix kubectl: If attach fails, fall back to printing the logs If attach fails, check the status again and if it's terminated, print the logs Fix the flaky test: Prevent the container from exiting (e.g. `sh -c 'echo running in container && sleep 30') Prevent the container from entering ready state (e.g. )
Thanks for debugging. I think we should probably do both: If attach fails and the container is now terminated, fall back to printing logs Make the e2e more robust by not exiting for a while to ensure time to attach. I'm happy to review PRs
Change:
// Test handleConnection pf.handleConnection(localConnection, ForwardedPort{Local: 1111, Remote: 2222}) <ins> assert.Equal(t, 0, remoteConnection.streamCount, "stream count should be zero") </ins> assert.Equal(t, "test data from local", remoteDataReceived.String()) assert.Equal(t, "test data from remote", localConnection.receiveBuffer.String()) assert.Equal(t, "Handling connection for 1111n", out.String())

Discussion:
The port forwarding client leaks memory when a port forwarding session is reused over time. The port forwarder client should not leak memory. forwarding a port with kubectl. and close many connections to the forwarded port. The amount of memory leaked for each connection is quite small, so many connections are needed to observe the leak. This is related to , which was reported for the kubelet and fixed in . However, the same problem happens to the client. The client needs to call on the , otherwise the streams created by will be kept in memory until the port forwarder itself is closed, even if the streams themselves closed long before. <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery
/cc /triage accepted
/cc
Change:
--disk "name=${MASTER_NAME}-pd,device-name=master-pd,mode=rw,boot=no,auto-delete=no" run-gcloud-compute-with-retries instances add-metadata "${MASTER_NAME}"  <ins> ${GCLOUD_COMMON_ARGS}  </ins> --metadata-from-file startup-script="${KUBE_ROOT}/test/kubemark/resources/start-kubemark-master.sh" if [ "${EVENT_PD:-false}" == "true" ]; then

Discussion:
I'm seeing the following in my logs: There was an errors, and we silently skipped it.
Good catch! Thanks for pointing.
Change:
if err != nil { klog.Warningf("Failed to load kernel module %v with modprobe. "+ "You can ignore this message when kube-proxy is running inside container without mounting /lib/modules", module) <ins> } else { lmods = append(lmods, module) </ins> } } } <del> return append(mods, bmods...), nil </del> <ins> mods = append(mods, bmods...) mods = append(mods, lmods...) return mods, nil </ins> } // getFirstColumn reads all the content from r into memory and return a

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 --What happened: When creating a new cluster using , panics with SIGSEGV on first run: Note that after the crash the pod restarts, and the second run is successful: and everything seems to be working as expected. What you expected to happen: starts successfully the first time. How to reproduce it (as minimally and precisely as possible): Create a new cluster using , with in mode. Anything else we need to know?: Environment: Kubernetes version (use ): 1.18.0 Cloud provider or hardware configuration: Hetzner VPS OS (e.g: ): Ubuntu 18.04.4 LTS Kernel (e.g. ): 5.3.0-45-generic (Ubuntu's default HWE kernel) Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others: using CRI and mode Please let me know if you need any additional information.
/sig network
/assign
According to the panic output, the crashed code is For some reason, might be nil, we should always check it before using.
Do we understand WHY it is nil?
One more thing I've noticed while fiddling with the cluster is that if I remove the node and re-join it, starts just fine, so I'm guessing it has to do with the initial state of the server / ipvs.
That would be my guess too. And that sort of race is worth fixing :)
do you see anything in the logs in the form: ??
I think somewhere here we're failing to initialize the IPVS interface. We probably shouldn't ignore the error from also :grimacing:
Nope, I posted the (full) logs in the issue description.
Thanks, will look into it deeper
do you happen to have a start up script that loads the necessary IPVS modules or is it preloaded on your nodes? Wondering if there could be a race between when the modules get loaded and when proxy starts up. Either way we should log the error ().
Neither, but if you give me the module list I can try to load them before creating the cluster to see if I still get the panic.

For kernel <4.19: For = 4.19:
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
I can confirm that, if I explicitly preload the modules, starts successfully the first time.
According to this log , we can confirm second check success, missing modules loaded after first failed check. Because missing modules loaded but not put to
Change:
ns := f.Namespace.Name createdPod := podClient.Create(pod) <ins> defer func() { By("delete the pod") podClient.DeleteSync(createdPod.Name, &api.DeleteOptions{}, podNoLongerRunningTimeout) }() </ins> // Wait for client pod to complete. if err := WaitForPodSuccessInNamespace(f.ClientSet, createdPod.Name, ns); err != nil {

Discussion:
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite} Previous issues for this test:
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
https://k8s- Failed: [] Pods should contain environment variables for services [Conformance] {E2eNode Suite}
This is beginning to happen more frequently, can someone from take a look please. CC
Change:
"//vendor:k8s.io/apimachinery/pkg/runtime/serializer/streaming", "//vendor:k8s.io/apimachinery/pkg/types", "//vendor:k8s.io/apimachinery/pkg/util/httpstream", <ins> "//vendor:k8s.io/apimachinery/pkg/util/json", </ins> "//vendor:k8s.io/apimachinery/pkg/util/mergepatch", "//vendor:k8s.io/apimachinery/pkg/util/net", "//vendor:k8s.io/apimachinery/pkg/util/runtime",

Discussion:
When patching, in the type decoded from ToUnstructured mismatch with the one decoded form json.Unmarshal for numbers. Example: port: 80 in original object has type int64 port: 80 in original object has type float64 This is the root cause of