jiebi/CodeConvo huggingface dataset:
Change:
"fmt" "net/http" "strconv" <ins> "sync" </ins> "testing" "time"

Discussion:
The standard event recorder, when recording an event, calls the underlying Broadcaster in a goroutine, so that even recording is non-blocking. Things like leader election emit events over the course of their lifecycle via this broadcaster. Consider the following scenario: GR1: spawn leader election ----GR2 GR2: Leader election: emit event "Lease Acquired" ----spawn GR3 () GR1: Shutdown leader election ----blocks until GR2 is done GR1: Shutdown broadcaster --() GR3: ----send on closed channel () Practically, we've observed this behavior popping up occaisionally in tests in controller-runtime:
/sig api-machinery /kind bug
<details<summaryrelevant race detector output/stack traces</summary</details
were you planning on sending a fix, or need our help to send one to fix it?
I can probably try to figure out a fix if you want, but the whole model for how event broadcasters currently work is inverse to how Go suggests you manage channels (only writers should ever close channels, not readers). I'll need to do a bit of playing around with things.
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
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
I think this is fixed by . Please reopen if it's not the case.
/triage accepted
Would be possible to cherry-pick this fix in 1.20?
Change:
}, wantErr: "already registered", }, <ins> { name: "Override MultiPoint plugins weights and avoid a plugin being loaded multiple times", plugins: &config.Plugins{ MultiPoint: config.PluginSet{ Enabled: []config.Plugin{ {Name: testPlugin}, {Name: scorePlugin1}, }, }, Score: config.PluginSet{ Enabled: []config.Plugin{ {Name: scorePlugin1, Weight: 5}, {Name: scorePlugin2, Weight: 5}, {Name: testPlugin, Weight: 3}, }, }, }, wantPlugins: &config.Plugins{ QueueSort:  config.PluginSet{Enabled: []config.Plugin{{Name: testPlugin}}}, PreFilter:  config.PluginSet{Enabled: []config.Plugin{{Name: testPlugin}}}, Filter:     config.PluginSet{Enabled: []config.Plugin{{Name: testPlugin}}}, PostFilter: config.PluginSet{Enabled: []config.Plugin{{Name: testPlugin}}}, PreScore: config.PluginSet{Enabled: []config.Plugin{ {Name: testPlugin}, {Name: scorePlugin1}, }}, Score: config.PluginSet{Enabled: []config.Plugin{ {Name: scorePlugin1, Weight: 5}, {Name: testPlugin, Weight: 3}, {Name: scorePlugin2, Weight: 5}, }}, Reserve:  config.PluginSet{Enabled: []config.Plugin{{Name: testPlugin}}}, Permit:   config.PluginSet{Enabled: []config.Plugin{{Name: testPlugin}}}, PreBind:  config.PluginSet{Enabled: []config.Plugin{{Name: testPlugin}}}, Bind:     config.PluginSet{Enabled: []config.Plugin{{Name: testPlugin}}}, PostBind: config.PluginSet{Enabled: []config.Plugin{{Name: testPlugin}}}, }, }, </ins> } for _, tc := range tests {

Discussion:
Scheduler's default plugin returns an invalid score that is not in the range of [0, 100], resulting in no Pods being scheduled: After investigation, I found that there was a bug in the code that built the framework when the scheduler started. When using the plugins declared in the regular extension point to override the plugins declared in the MultiPoint, the traversed variable will be modified in the following loop: This may cause a same scoring plugin (e.g. ) to be loaded multiple times: Further, this results in a node being processed multiple times by a plugin's (e.g. 's) method, resulting in an invalid score that is not in the range of [0, 100]: If the scheduler's MultiPoint feature is used (either through the default plugins or through manual configuration), and the configuration (e.g. the scoring weight) of a certain plugin is overridden in a regular extension point, the plugin will only be loaded once in this extension point, and no illegal scores will be returned. An example KubeSchedulerConfiguration: No response K8s v1.24.15 or higher None <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
/sig scheduling
Can I work on this?
this is being worked on. see
I see, Is there any other task that you are aware of and I can work on? Thanks.
Change:
the each of service proxy endpoints in the cluster using a http post(protocol=udp)  and the request MUST be successful. Container will execute curl command to reach the service port within specified max retry limit and MUST result in reporting unique <del> hostnames. </del> <ins> hostnames. This test is marked LinuxOnly it breaks when using Overlay networking with Windows. </ins> release: v1.9 file: test/e2e/common/network/networking.go - testname: Proxy, validate Proxy responses

Discussion:
ci-kubernetes-e2e-capz-master-containerd-windows should function for node-pod communication: http [NodeConformance] should function for node-pod communication: udp [NodeConformance] PR merged on April 4th 2022 Discussed at sig-windows triage meeting as well as regular meeting: This test is passing for flannel overlay: and aks-engine: We plan temporary disable this on the CAPZ test suite while we diagnose what is missing. /sig windows /sig networking /cc
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : ### Which jobs are failing? should function for node-pod communication: udp [NodeConformance] ### Since when has it been failing? /sig networking 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
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 network Did some looking into this and the tests is not deploying a hostprocess pod for Windows: Following the test flow Creates test pods: Then the hostnetwork is set to true but the windows Hostprocess fields are not set:
This pod being tested has which seems to be causing issues with calico, if I remove that then it works (as the other tests that do pod-pod demonstrate). Once I switched this test to use a hostprocess this test works for on the same host when using Windows overlay. Overlay has this limitation that we have seen before: fail (according to the , it is not mandatory for kubelet to be able to access pods on a different node).
My thoughts are we should disable these two tests for 1.24 because they are not testing what they should be and it requires some tough changes to the framework to make it work as is. These tests also doesn't make sense for . A example of the changes need to make this partially work on l2bridge but not overlay:
Change:
# KUBE_USE_EXISTING_MASTER is used to add minions to an existing master if [[ "${KUBE_USE_EXISTING_MASTER:-}" == "true" ]]; then <del> # Detect existing master </del> detect-master <ins> parse-master-env </ins> # Start minions start-minions

Discussion:
When we add nodes to an existing cluster, we need to reuse the existing configuration. In particular, we need to extract the kubelet cert & key, otherwise we get a cert error connecting to the master.
WIP fix in
Change:
By("deleting host0Pod") framework.ExpectNoError(podClient.Delete(host0Pod.Name, api.NewDeleteOptions(0)), "Failed to delete host0Pod") } <ins> By("Test completed successfully, waiting for PD to safely detach") waitForPDDetach(diskName, host0Name) </ins> }) It("should schedule a pod w/two RW PDs both mounted to one container, write to PD, verify contents, delete pod, recreate pod, verify contents, and repeat in rapid succession [Slow]", func() {

Discussion:
PD E2E tests have very aggressive clean up routine that does not wait for volumes to safely detached. After the test completes, the test cleanup routine unilaterally detaches the PD (instead of waiting for k8s to do it cleanly). Although this does not cause the test to fail, it results in errors in the kernel logs: We should modify these tests to wait for k8s to safely detach the disk.
Change:
if len(plist.FrontendVIPs) == 0 || plist.FrontendVIPs[0] != vip { continue } <ins> } else if len(plist.FrontendVIPs) != 0 { continue </ins> } LogJson(plist, "Found existing Hns loadbalancer policy resource", 1) return &loadBalancerInfo{

Discussion:
What happened: I created a service where the was the same as the , and having done so, then the was not accessible externally on the Windows node where the pod was running (it was, however, accessible on the Linux master). When I changed either the or the so that they were different then the service was accessible on the Windows node. What you expected to happen: I expect services to work when the and the are the same value. How to reproduce it (as minimally and precisely as possible): Here's the file that I used: Then, in a web browser on my desktop machine, I visited the on both the Linux master's IP address, and then in a different tab, using the again, the IP address of the Windows worker node where that pod was scheduled. It only worked using the IP address of the Linux master. The tab using the Windows worker node's IP address did not load. Then, I changed either the or the so that they were different values, and when they were different, it worked using the of both the Linux master's IP address and the IP address of the Windows worker node where that pod was scheduled. Anything else we need to know?: On-premise install of k8s The Windows nodes all have the following feature gates enabled: WinOverlay WindowsGMSA Linux master: OS (e.g. ): Windows worker: If you need any more information then please let me know.
Reiterating the mentions to trigger a notification: <detailsIn response to : 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 you take a look?
Change:
By("Running pods to generate events while waiting for some of them to be ingested") wait.PollUntil(eventCreationInterval, func() (bool, error) { podName := "synthlogger" <del> createLoggingPod(f, podName, "", 1, 1*time.Second) </del> <ins> startNewLoggingPod(f, podName, "", 1, 1*time.Second) </ins> defer f.PodClient().Delete(podName, &meta_v1.DeleteOptions{}) err = framework.WaitForPodSuccessInNamespace(f.ClientSet, podName, f.Namespace.Name) if err != nil {

Discussion:
Pods should be run in parallel with checking the logs from the backend to fit into the timeout.
Change:
) # tell the user which we've selected and lint all scripts <ins> # The shellcheck errors are printed to stdout by default, hence they need to be redirected # to stderr in order to be well parsed for Junit representation by juLog function </ins> res=0 if ${HAVE_SHELLCHECK}; then echo "Using host shellcheck ${SHELLCHECK_VERSION} binary." <del> shellcheck "${SHELLCHECK_OPTIONS[@]}" "${all_shell_scripts[@]}" || res=$? </del> <ins> shellcheck "${SHELLCHECK_OPTIONS[@]}" "${all_shell_scripts[@]}" >&2 || res=$? </ins> else echo "Using shellcheck ${SHELLCHECK_VERSION} docker image." "${DOCKER}" run  --rm -v "${KUBE_ROOT}:${KUBE_ROOT}" -w "${KUBE_ROOT}"  "${SHELLCHECK_IMAGE}"  <del> shellcheck "${SHELLCHECK_OPTIONS[@]}" "${all_shell_scripts[@]}" || res=$? </del> <ins> shellcheck "${SHELLCHECK_OPTIONS[@]}" "${all_shell_scripts[@]}" >&2 || res=$? </ins> fi # print a message based on the result

Discussion:
junit output: full output with actual error (expand build- and grep around) we want the actual error to be included in the junit so it will be displayed at the top, right now the error at the top is confusing and useless. /sig testing
/assign
Change:
<del> #!/bin/bash if [[ "$(grep -c "COMMIT_BLOCKED" $1)" -gt 0 ]]; then echo "FAILED: Unresolved errors - aborting the commit." echo "The message of your attempted commit was:" cat $1 exit 1 fi exit 0 </del>

Discussion:
Multiple, for example: Since See above The test tolerations are now to strict: No response /sig node
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
I think it's from if you check the cri-o versions the succeessful one was and the failing was
Working on a fix in
cc
/reopen need to bump in kube as well to fully get the fix
Reopened this issue. <detailsIn response to : /reopen </details
Change:
podClient = f.PodClient() }) <ins> Context("when pod PID namespace is configurable [Feature:ShareProcessNamespace]", func() { It("containers in pods using isolated PID namespaces should all receive PID 1", func() { By("Create a pod with isolated PID namespaces.") f.PodClient().CreateSync(&v1.Pod{ ObjectMeta: metav1.ObjectMeta{Name: "isolated-pid-ns-test-pod"}, Spec: v1.PodSpec{ Containers: []v1.Container{ { Name:    "test-container-1", Image:   "busybox", Command: []string{"/bin/top"}, }, { Name:    "test-container-2", Image:   "busybox", Command: []string{"/bin/sleep"}, Args:    []string{"10000"}, }, }, }, }) By("Check if both containers receive PID 1.") pid1 := f.ExecCommandInContainer("isolated-pid-ns-test-pod", "test-container-1", "/bin/pidof", "top") pid2 := f.ExecCommandInContainer("isolated-pid-ns-test-pod", "test-container-2", "/bin/pidof", "sleep") if pid1 != "1" || pid2 != "1" { framework.Failf("PIDs of different containers are not all 1: test-container-1=%v, test-container-2=%v", pid1, pid2) } }) It("processes in containers sharing a pod namespace should be able to see each other [Alpha]", func() { By("Check whether shared PID namespace is supported.") isEnabled, err := isSharedPIDNamespaceSupported() framework.ExpectNoError(err) if !isEnabled { framework.Skipf("Skipped because shared PID namespace is not supported by this docker version.") } // It's not enough to set this flag in the kubelet because the apiserver needs it too if !utilfeature.DefaultFeatureGate.Enabled(features.PodShareProcessNamespace) { framework.Skipf("run test with --feature-gates=PodShareProcessNamespace=true to test PID namespace sharing") } By("Create a pod with shared PID namespace.") f.PodClient().CreateSync(&v1.Pod{ ObjectMeta: metav1.ObjectMeta{Name: "shared-pid-ns-test-pod"}, Spec: v1.PodSpec{ ShareProcessNamespace: &[]bool{true}[0], Containers: []v1.Container{ { Name:    "test-container-1", Image:   "busybox", Command: []string{"/bin/top"}, }, { Name:    "test-container-2", Image:   "busybox", Command: []string{"/bin/sleep"}, Args:    []string{"10000"}, }, }, }, }) By("Check if the process in one container is visible to the process in the other.") pid1 := f.ExecCommandInContainer("shared-pid-ns-test-pod", "test-container-1", "/bin/pidof", "top") pid2 := f.ExecCommandInContainer("shared-pid-ns-test-pod", "test-container-2", "/bin/pidof", "top") if pid1 != pid2 { framework.Failf("PIDs are not the same in different containers: test-container-1=%v, test-container-2=%v", pid1, pid2) } }) }) </ins> Context("when creating a pod in the host PID namespace", func() { makeHostPidPod := func(podName, image string, command []string, hostPID bool) *v1.Pod { return &v1.Pod{

Discussion:
Once the API for is finalized, add a node e2e test. /kind feature /assign /cc /sig node
We plan on adding this for 1.10
Change:
} // EqualIgnoreHash returns true if two given podTemplateSpec are equal, ignoring the diff in value of Labels[pod-template-hash] <del> // We ignore pod-template-hash because the hash result would be different upon podTemplateSpec API changes // (e.g. the addition of a new field will cause the hash code to change) // Note that we assume input podTemplateSpecs contain non-empty labels </del> <ins> // We ignore pod-template-hash because: // 1. The hash result would be different upon podTemplateSpec API changes //    (e.g. the addition of a new field will cause the hash code to change) // 2. The deployment template won't have hash labels </ins> func EqualIgnoreHash(template1, template2 *v1.PodTemplateSpec) bool { t1Copy := template1.DeepCopy() t2Copy := template2.DeepCopy() <del> // First, compare template.Labels (ignoring hash) labels1, labels2 := t1Copy.Labels, t2Copy.Labels if len(labels1) > len(labels2) { labels1, labels2 = labels2, labels1 } // We make sure len(labels2) >= len(labels1) for k, v := range labels2 { if labels1[k] != v && k != extensions.DefaultDeploymentUniqueLabelKey { return false } } // Then, compare the templates without comparing their labels t1Copy.Labels, t2Copy.Labels = nil, nil </del> <ins> // Remove hash labels from template.Labels before comparing delete(t1Copy.Labels, extensions.DefaultDeploymentUniqueLabelKey) delete(t2Copy.Labels, extensions.DefaultDeploymentUniqueLabelKey) </ins> return apiequality.Semantic.DeepEqual(t1Copy, t2Copy) }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig apps What happened: Attempting a on a deployment where the only change between revisions is the addition of a single label fails with . The addition of more than one label will successfully be detected as a Template change and the rollback will occur successfully. Example: The additional label was to the pod template (both and were tested) and a new ReplicaSet with a unique pod-template-hash was generated. revision 1 revision 2 Rollout undo Repeating the above steps but adding an additional label does successfully trigger a successful What you expected to happen: The deployment is able to be successfully rolled back. How to reproduce it (as minimally and precisely as possible): 1) Create a deployment (use example above) 2) Update the deployment by adding a single additional label to the Pod Template 3) Attempt to rollback to the revision without the single additional label Anything else we need to know?: Tested both with and Environment: Kubernetes version (use ): minikube gke Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): client: OSX High Sierra minikube: v0.25.2 / Buildroot 2017.11 gke: Container-Optimized OS from Google
thanks for reporting this! It's a bug in the template comparison function. A fix is underway.
Change:
ConfigOrDie(name string) *restclient.Config Client(name string) (clientset.Interface, error) ClientOrDie(name string) clientset.Interface <ins> DiscoveryClient(name string) (discovery.DiscoveryInterface, error) DiscoveryClientOrDie(name string) discovery.DiscoveryInterface </ins> } // SimpleControllerClientBuilder returns a fixed client with different user agents

Discussion:
Ran kube-controller-manager with and observed this in the log every 30 seconds: This is also happening in 1.20, 1.19, and 1.18 The GC and quota clients look up discovery information every 30 seconds. They have a QPS of 20 requests per second and a burst of 30 requests. Default configuration of kube-controller-manager runs without constant throttling warnings. /sig api-machinery
/assign /triage accepted
Change:
if status == nil { t.Errorf("Unexpected non-status.") } <del> expected := &api.PodStatus{ Phase:  "Pending", Host:   "machine", HostIP: "1.2.3.5", Info: api.PodInfo{ "bar": api.ContainerStatus{}, }, } if !reflect.DeepEqual(status, expected) { t.Errorf("expected:n%#vngot:n%#vn", expected, status) } </del> } type podCacheTestConfig struct {

Discussion:
Kubelet now only reports ContainerStatus. PodStatus / PodCondition is observed at master side based on a set of ContainerStatus. There is no other way to get PodIP except net container for master side. This is very confusion to the end user, , , ... Now we are finalizing on v1beta3 API, including PodStatus & ContainerStatus. We can make net container completely invisible to the end users by finishing the following steps: 1) Expose network related errors at API level 2) Generate PodStaus directly from Kubelet
3) once PodStatus generated by kubelet, PodIP can be removed from ContainerStatus.
I think reporting PodStatus rather than just container status is most important. How hard is that?
Used to be hard since there are many dependencies when I first report Status back. Now it is totally feasible. I already started to write PRs for this. :-)
One more PR required to close this one.
Change:
for _, item := range indexResults { found.Insert(item.(*v1.Pod).Name) } <del> items := v.List() if !found.HasAll(items...) { t.Errorf("missing items, index %s, expected %v but found %v", k, items, found.List()) </del> <ins> if !found.Equal(v) { t.Errorf("missing items, index %s, expected %v but found %v", k, v.List(), found.List()) </ins> } } }

Discussion:
second will cancel the first set, as a result, the is checking empty list which will always be true. this test should fail.
/sig testing
A set is immutable, and by definition cannot support two of the same key name. We should have to change the data structure for this to pass, no?
/assign After read , size check would be a way to solve this problem. I try to fix this in
/sig apimachinery /remove-sig testing sig testing owns the frameworks, infrastructure, etc. SIG api-machinery owns their unit tests / client-go
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig apimachinery /remove-sig testing 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
/sig api-machinery
/triage accepted