jiebi/CodeConvo huggingface dataset:
Change:
What happened: two scheduler metrics, and , was not recorded in . scheduler has some code for this already. It seems to be a bug. What you expected to happen: and was recorded How to reproduce it (as minimally and precisely as possible): /king bug /sig scheduling
/assign
What do you expect for ? And I think pending pods are available in metrics, but not from scheduler. You can get it from pods info metrics.
actually, scheduler has some code already for recording these metrics. But I found a bug in these code. I will post my PR to fix this issue soon. // I updated the issue description for clarifying.

Discussion:
StabilityLevel: metrics.ALPHA, }, []string{"result"}) // PodScheduleSuccesses counts how many pods were scheduled. <ins> // This metric will be initialized again in Register() to assure the metric is not no-op metric. </ins> PodScheduleSuccesses = scheduleAttempts.With(metrics.Labels{"result": "scheduled"}) // PodScheduleFailures counts how many pods could not be scheduled. <ins> // This metric will be initialized again in Register() to assure the metric is not no-op metric. </ins> PodScheduleFailures = scheduleAttempts.With(metrics.Labels{"result": "unschedulable"}) // PodScheduleErrors counts how many pods could not be scheduled due to a scheduler error. <ins> // This metric will be initialized again in Register() to assure the metric is not no-op metric. </ins> PodScheduleErrors            = scheduleAttempts.With(metrics.Labels{"result": "error"}) DeprecatedSchedulingDuration = metrics.NewSummaryVec( &metrics.SummaryOpts{

legacyregistry.MustRegister(metric) } volumeschedulingmetrics.RegisterVolumeSchedulingMetrics() <ins> PodScheduleSuccesses = scheduleAttempts.With(metrics.Labels{"result": "scheduled"}) PodScheduleFailures = scheduleAttempts.With(metrics.Labels{"result": "unschedulable"}) PodScheduleErrors = scheduleAttempts.With(metrics.Labels{"result": "error"}) </ins> }) }

nodeInfoSnapshot:               snapshot, } <ins> metrics.Register() </ins> var sched *Scheduler source := options.schedulerAlgorithmSource switch {

default: return nil, fmt.Errorf("unsupported algorithm source: %v", source) } <del> metrics.Register() </del> // Additional tweaks to the config produced by the configurator. sched.Recorder = recorder sched.DisablePreemption = options.disablePreemption
Change:
/kind cleanup /sig storage /sig node /sig testing Description: Change e2e tests to use EmptyDir instead of HostPath as pre-requisite to promoting VolumeSubpathEnvExpansion to Conformance. Related Issues: Conformance Tests:
/cc
/assign

Discussion:
SubPathExpr: "$(POD_NAME)", }, { <del> Name:      "workdir2", </del> <ins> Name:      "workdir1", </ins> MountPath: "/testcontainer", }, },

SubPathExpr: "$(ANNOTATION)/$(POD_NAME)", }, { <del> Name:      "workdir2", </del> <ins> Name:      "workdir1", </ins> MountPath: "/volume_mount", }, },

MountPath: "/subpath_mount", }, { <del> Name:      "workdir2", </del> <ins> Name:      "workdir1", </ins> MountPath: "/volume_mount", }, },

SubPathExpr: "$(POD_NAME)", }, { <del> Name:      "workdir2", </del> <ins> Name:      "workdir1", </ins> MountPath: "/volume_mount", }, },

{ Name: "workdir1", VolumeSource: v1.VolumeSource{ <del> HostPath: &v1.HostPathVolumeSource{Path: "/tmp"}, }, }, { Name: "workdir2", VolumeSource: v1.VolumeSource{ HostPath: &v1.HostPathVolumeSource{Path: "/tmp"}, </del> <ins> EmptyDir: &v1.EmptyDirVolumeSource{}, </ins> }, }, },
Change:
Tests in are failing because they are faulty. A container can't read from a file if it has selinux permission denied for it. More context - /sig node /sig storage
something we can look into.
Also,
The tests expect that SELinux blocks a pod with label "s0:c2,c3" reading a file created by a pod with label "s0:c0,c1". Since the tests runs on GCI, where SELinux is not available, nothing blocks the read and the tests can't ever pass. The tests should check that the node has SELinux in Enforcing mode and skip the tests otherwise. Somewhere around these parts, where we write/read a file in the first "s0:c0,c1" pod: Is there an easy way how to test that in /proc or /sys in a non-privileged busybox container?
There are two problems. First one is obviously - the test can't run on non-selinux systems, but second one is - it is also broken on selinux enabled systems as per
To check whether SELinux is in enforced mode, one can check that read returns "1". I've implemented that in a particular case that relies on selinux being enforced: To check whether SELinux is enabled (I guess this is a prerequisite for all the test cases in ), one can use from (which of course should be run in a proper context). In case a check for a particular container is needed, the presence of directory should be enough. Having said that, I'm not sure how to properly wrap the above check(s) into (or , or whatever).

Discussion:
"context" "fmt" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/kubernetes/test/e2e/framework"

pod.Spec.SecurityContext.SELinuxOptions = &v1.SELinuxOptions{ Level: "s0:c0,c1", } f.TestContainerOutput("Pod with same MCS label reading test file", pod, 0, []string{testContent}) // Confirm that the same pod with a different MCS // label cannot access the volume <ins> ginkgo.By("confirming a container with a different MCS label is unable to read the file") </ins> pod = scTestPod(hostIPC, hostPID) pod.Spec.Volumes = volumes pod.Spec.Containers[0].VolumeMounts = volumeMounts

err = f.WaitForPodRunning(pod.Name) framework.ExpectNoError(err, "Error waiting for pod to run %v", pod) <del> content, err = tk.ReadFileViaContainer(pod.Name, "test-container", testFilePath) framework.ExpectNoError(err, "Error reading file via container") gomega.Expect(content).NotTo(gomega.ContainSubstring(testContent)) </del> <ins> // for this to work, SELinux should be in enforcing mode, so let's check that isEnforced, err := tk.ReadFileViaContainer(pod.Name, "test-container", "/sys/fs/selinux/enforce") if err == nil && isEnforced == "1" { _, err = tk.ReadFileViaContainer(pod.Name, "test-container", testFilePath) framework.ExpectError(err, "expecting SELinux to not let the container with different MCS label to read the file") } </ins> }
Change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : kube-controller-manager currently does not expose work queue metrics Why is this needed: queuing delay and queue length are important information to debug control plane performance in large scale cluster /assign zhan849 /sig apps

Discussion:
"//staging/src/k8s.io/client-go/kubernetes:go_default_library", "//staging/src/k8s.io/component-base/config:go_default_library", "//staging/src/k8s.io/component-base/metrics/legacyregistry:go_default_library", <ins> "//staging/src/k8s.io/component-base/metrics/prometheus/workqueue:go_default_library", </ins> "//vendor/k8s.io/klog:go_default_library", ], )

"k8s.io/apiserver/pkg/server/routes" componentbaseconfig "k8s.io/component-base/config" "k8s.io/component-base/metrics/legacyregistry" <ins> _ "k8s.io/component-base/metrics/prometheus/workqueue" // for workqueue metric registration </ins> "k8s.io/kubernetes/pkg/api/legacyscheme" "k8s.io/kubernetes/pkg/util/configz" )
Change:
When a test run completes it would be useful to have a list of all the test containers that were pulled onto the node - see for the motivation. Let's add a call to at - just after seems like it should work fine. We can dump the output to a file and gather it from each node just like we do for
/assign Yang, we should also consider adding to the log gathering that the GCE diagnostics tool does :)
/sig windows
/reopen in the of our on 03-22 I don't see in the artifacts for the Windows node. Can you check on this? Did we miss a step or is something failing?
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
Oh, missed to add the new log file to collector list.
Added the fix:

Discussion:
done } <ins> # Saves prepulled Windows Docker images list to ${WINDOWS_LOGS_DIR}docker_images.log # on node $1. function export-windows-docker-images-list() { local -r node="${1}" local -r powershell_cmd="powershell.exe -Command "$logs=$(docker image list); $logs | Out-File -FilePath '${WINDOWS_LOGS_DIR}docker_images.log'"" # Retry up to 3 times to allow ssh keys to be properly propagated and # stored. for retry in {1..3}; do if gcloud compute ssh --project "${PROJECT}" --zone "${ZONE}" "${node}"  --command "$powershell_cmd"; then break else sleep 10 fi done } </ins> # Saves log files from diagnostics tool.(https://github.com/GoogleCloudPlatform/compute-image-tools/tree/master/cli_tools/diagnostics) function save-windows-logs-via-diagnostics-tool() { local node="${1}"

local dest_dir="${2}" export-windows-docker-event-log "${node}" <ins> export-windows-docker-images-list "${node}" </ins> local remote_files=() for file in ${windows_node_logfiles[@]}; do remote_files+=( "${WINDOWS_LOGS_DIR}${file}" )
Change:
When a test run completes it would be useful to have a list of all the test containers that were pulled onto the node - see for the motivation. Let's add a call to at - just after seems like it should work fine. We can dump the output to a file and gather it from each node just like we do for
/assign Yang, we should also consider adding to the log gathering that the GCE diagnostics tool does :)
/sig windows
/reopen in the of our on 03-22 I don't see in the artifacts for the Windows node. Can you check on this? Did we miss a step or is something failing?
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
Oh, missed to add the new log file to collector list.
Added the fix:

Discussion:
readonly extra_log_files="${LOG_DUMP_EXTRA_FILES:-}" readonly dump_systemd_journal="${LOG_DUMP_SYSTEMD_JOURNAL:-false}" # Log files found in WINDOWS_LOGS_DIR on Windows nodes: <del> readonly windows_node_logfiles="kubelet.log kube-proxy.log docker.log" </del> <ins> readonly windows_node_logfiles="kubelet.log kube-proxy.log docker.log docker_images.log" </ins> # Log files found in other directories on Windows nodes: readonly windows_node_otherfiles="C:WindowsMEMORY.dmp"
Change:
<!-- 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: azure disk migration does not work on CSINode What you expected to happen: 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: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure

Discussion:
csitranslationplugins.CinderInTreePluginName: func() bool { return utilfeature.DefaultFeatureGate.Enabled(features.CSIMigration) && utilfeature.DefaultFeatureGate.Enabled(features.CSIMigrationOpenStack) }, <ins> csitranslationplugins.AzureDiskInTreePluginName: func() bool { return utilfeature.DefaultFeatureGate.Enabled(features.CSIMigration) && utilfeature.DefaultFeatureGate.Enabled(features.CSIMigrationAzureDisk) }, csitranslationplugins.AzureFileInTreePluginName: func() bool { return utilfeature.DefaultFeatureGate.Enabled(features.CSIMigration) && utilfeature.DefaultFeatureGate.Enabled(features.CSIMigrationAzureFile) }, </ins> } // Initializing the label management channels
Change:
<!-- 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: regarding - yes it polls every second, but if /dev/... is not there (findDiskByLun returns "") it returns fmt.Errorf("azureDisk - findDiskByLun(%v) failed within timeout", lun). and exits from wait.Poll It causes to kubelet retry NodePublishVolume with exponensial backoff, and because /dev/disk/azure/... can appear 15-60s after first first call it can reach 2m timeout. So I suggest to just return false, nil and let wait.Poll to retry instead of kubelet. see What you expected to happen: 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: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure

Discussion:
return true, nil } <del> return false, fmt.Errorf("azureDisk - WaitForAttach failed within timeout node (%s) diskId:(%s) lun:(%v)", nodeName, diskName, lun) </del> <ins> // wait until timeout return false, nil </ins> }) <ins> if err == nil && newDevicePath == "" { err = fmt.Errorf("azureDisk - WaitForAttach failed within timeout node (%s) diskId:(%s) lun:(%v)", nodeName, diskName, lun) } </ins> return newDevicePath, err }
Change:
What happened: A missing test case was found for NetworkPolicy with Except clause What you expected to happen: Expect Except clause test to be covered
/sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved

Discussion:
}) }) <ins> ginkgo.It("should enforce except clause while egress access to server in CIDR block [Feature:NetworkPolicy]", func() { protocolUDP := v1.ProtocolUDP // Getting podServer's status to get podServer's IP, to create the CIDR with except clause podServerStatus, err := f.ClientSet.CoreV1().Pods(f.Namespace.Name).Get(context.TODO(), podServer.Name, metav1.GetOptions{}) if err != nil { framework.ExpectNoError(err, "Error occurred while getting pod status.") } podServerAllowCIDR := fmt.Sprintf("%s/24", podServerStatus.Status.PodIP) // Exclude podServer's IP with an Except clause podServerExceptList := []string{fmt.Sprintf("%s/32", podServerStatus.Status.PodIP)} // client-a can connect to server prior to applying the NetworkPolicy ginkgo.By("Creating client-a which should be able to contact the server.", func() { testCanConnect(f, f.Namespace, "client-a", service, 80) }) policyAllowCIDRWithExcept := &networkingv1.NetworkPolicy{ ObjectMeta: metav1.ObjectMeta{ Namespace: f.Namespace.Name, Name:      "deny-client-a-via-except-cidr-egress-rule", }, Spec: networkingv1.NetworkPolicySpec{ // Apply this policy to the client. PodSelector: metav1.LabelSelector{ MatchLabels: map[string]string{ "pod-name": "client-a", }, }, PolicyTypes: []networkingv1.PolicyType{networkingv1.PolicyTypeEgress}, // Allow traffic to only one CIDR block except subnet which includes Server. Egress: []networkingv1.NetworkPolicyEgressRule{ { Ports: []networkingv1.NetworkPolicyPort{ // Allow DNS look-ups { Protocol: &protocolUDP, Port:     &intstr.IntOrString{Type: intstr.Int, IntVal: 53}, }, }, }, { To: []networkingv1.NetworkPolicyPeer{ { IPBlock: &networkingv1.IPBlock{ CIDR:   podServerAllowCIDR, Except: podServerExceptList, }, }, }, }, }, }, } policyAllowCIDRWithExcept, err = f.ClientSet.NetworkingV1().NetworkPolicies(f.Namespace.Name).Create(context.TODO(), policyAllowCIDRWithExcept, metav1.CreateOptions{}) framework.ExpectNoError(err, "Error occurred while creating policy: policyAllowCIDRWithExcept.") defer cleanupNetworkPolicy(f, policyAllowCIDRWithExcept) ginkgo.By("Creating client-a which should no longer be able to contact the server.", func() { testCannotConnect(f, f.Namespace, "client-a", service, 80) }) }) </ins> ginkgo.It("should enforce policies to check ingress and egress policies can be controlled independently based on PodSelector [Feature:NetworkPolicy]", func() { var serviceA, serviceB *v1.Service var podA, podB *v1.Pod
Change:
<!-- 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: check disk status before disk azure disk There is little possibility that attach disk would cost 10min, and disk could be attached, deleted in same time, that would cause race condition. What you expected to happen: 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: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure

Discussion:
return fmt.Errorf("failed to delete disk(%s) since it's in attaching or detaching state", diskURI) } <del> rerr := c.common.cloud.DisksClient.Delete(ctx, resourceGroup, diskName) </del> <ins> disk, rerr := c.common.cloud.DisksClient.Get(ctx, resourceGroup, diskName) if rerr != nil { return rerr.Error() } if disk.ManagedBy != nil { return fmt.Errorf("disk(%s) already attached to node(%s), could not be deleted", diskURI, *disk.ManagedBy) } rerr = c.common.cloud.DisksClient.Delete(ctx, resourceGroup, diskName) </ins> if rerr != nil { return rerr.Error() }
Change:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : when using kubeadm init include Why is this needed: the log only show extra-volumes for that control-plane? like this
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig kubeadm 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
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig kubeadm 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
/area kubeadm /kind cleanup /sig cluster-lifecycle
what version of kubeadm are you using?
this minor issue is in master too. the fix is in this PR:

Discussion:
return errors.Errorf("couldn't retrieve StaticPodSpec for %q", componentName) } <ins> // print all volumes that are mounted for _, v := range spec.Spec.Volumes { klog.V(2).Infof("[control-plane] adding volume %q for component %q", v.Name, componentName) } </ins> // if kustomizeDir is defined, customize the static pod manifest if kustomizeDir != "" { kustomizedSpec, err := staticpodutil.KustomizeStaticPod(&spec, kustomizeDir)

// paths in the case that a user specifies the same volume/volume mount name. func (c *controlPlaneHostPathMounts) AddExtraHostPathMounts(component string, extraVols []kubeadmapi.HostPathMount) { for _, extraVol := range extraVols { <del> fmt.Printf("[control-plane] Adding extra host path mount %q to %qn", extraVol.Name, component) </del> hostPathType := extraVol.PathType c.NewHostPathMount(component, extraVol.Name, extraVol.HostPath, extraVol.MountPath, extraVol.ReadOnly, &hostPathType) }
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: All the v1.18 / master jobs in: Which test(s) are failing: [sig-windows] Hybrid cluster network for all supported CNIs should have stable networking for Linux and Windows pods Since when has it been failing: Since this was merged: Testgrid link: Reason for failure: Previously, we've centralized several images into agnhost, including test-webserver. The Hybrid cluster network test was using the test-webserver image, and was updated to use agnhost, but without properly making it so it behaves like test-webserver, resulting in a failing test. Anything else we need to know: /sig windows /sig testing /priority important-soon

Discussion:
ginkgo.It("should have stable networking for Linux and Windows pods", func() { ginkgo.By("creating linux and windows pods") linuxPod := createTestPod(f, linuxBusyBoxImage, linuxOS) <ins> linuxPod = f.PodClient().CreateSync(linuxPod) </ins> windowsPod := createTestPod(f, windowsBusyBoximage, windowsOS) windowsPod.Spec.Containers[0].Args = []string{"test-webserver"} <ins> windowsPod = f.PodClient().CreateSync(windowsPod) </ins> ginkgo.By("checking connectivity to 8.8.8.8 53 (google.com) from Linux") assertConsistentConnectivity(f, linuxPod.ObjectMeta.Name, linuxOS, linuxCheck("8.8.8.8", 53))

}, } } <del> return f.PodClient().CreateSync(pod) </del> <ins> return pod </ins> }
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: None, test is excluded Which test(s) are failing: Since when has it been failing: Unsure Testgrid link: Currently excluded Reason for failure: All 3 nodes have , of which is allocatable. The test was trying to schedule pods with 11009703Ki if I'm understanding the logs correctly. I think 3 pods should have started and 4th should have failed. Maybe the test needs to be updated to wait for 3/4 to start, not 4/4 but that's just a guess. Anything else we need to know: /sig windows
/assign

Discussion:
ginkgo.Context("attempt to deploy past allocatable memory limits", func() { ginkgo.It("should fail deployments of pods once there isn't enough memory", func() { <del> overrideAllocatableMemoryTest(f, 4) </del> <ins> overrideAllocatableMemoryTest(f, framework.TestContext.CloudConfig.NumNodes) </ins> }) })
Change:
What happened: When using sonobuoy to run some community tests, I realized that ginkgo was not invoked properly. More precisely, when invoking sonobuoy like this: I saw the following in the sonobuoy logs: Because I am running the tests in parallel, and sonobuoy does not set , the code defaults to (see ) for , and is set to . This is not the intended regex (should be ) and all the tests are skipped (because all test names have an ). What you expected to happen: should be set to so that only the tests with the "tag" are skipped. How to reproduce it (as minimally and precisely as possible): Use the sonobuoy command provided above. Environment:
I opened a PR for this
/sig testing

Discussion:
}, expectArgs: []string{ "ginkgobin", "--p", <del> "--focus=", "--skip=[Serial]", </del> <ins> "--focus=", "--skip=[Serial]", </ins> "--noColor=true", "testbin", "--", "--disable-log-dump", "--repo-root=/kubernetes", "--provider=", "--report-dir=", "--kubeconfig=",

extraArgsSeparaterEnvKey = "E2E_EXTRA_ARGS_SEP" defaultSkip         = "" <del> defaultFocus        = "[Conformance]" </del> <ins> defaultFocus        = "[Conformance]" </ins> defaultProvider     = "local" defaultParallel     = "1" defaultResultsDir   = "/tmp/results"

// serialTestsRegexp is the default skip value if running in parallel. Will not // override an explicit E2E_SKIP value. <del> serialTestsRegexp = "[Serial]" </del> <ins> serialTestsRegexp = "[Serial]" </ins> )