jiebi/CodeConvo huggingface dataset:
Change:
The volume snapshot controller tests can result in an empty VolumeSnapshot being taken if NodeUnstageVolume occurs after the VolumeSnapshot is taken. Previously there was a change made in Windows to ensure that NodeUnstageVolume finishes before continuing with the test; however, this needs to also to be included in other distros as well. NodeUnpublish, which removes the bind mount, does not force the caches to flush. Tests - The CI jobs should pass when running with a non-hostpath driver. I'm uncertain on why we've seen an increase in these failures, but running the following tests with a non-hostpath driver appear to flake regularly: [Testpattern: Pre-provisioned Snapshot (retain policy)] snapshottable[Feature:VolumeSnapshotDataSource] volume snapshot controller should check snapshot fields, check restore correctly works after modifying source data, check deletion [Testpattern: Pre-provisioned Snapshot (delete policy)] snapshottable[Feature:VolumeSnapshotDataSource] volume snapshot controller should check snapshot fields, check restore correctly works after modifying source data, check deletion [Testpattern: Dynamic Snapshot (retain policy)] snapshottable[Feature:VolumeSnapshotDataSource] volume snapshot controller should check snapshot fields, check restore correctly works after modifying source data, check deletion [Testpattern: Dynamic Snapshot (delete policy)] snapshottable[Feature:VolumeSnapshotDataSource] volume snapshot controller should check snapshot fields, check restore correctly works after modifying source data, check deletion In these tests we've seen the following with the AWS EBS CSI Driver. Driver logs on the node: In the driver logs (in the controller pod) I can see:
/sig storage
/triage accepted /priority important-soon all snapshot tests with real CSI drivers are quite flaky, I saw it at least in AWS, Azure and GCE in a downstream CI job

Discussion:
nodeName := pod.Spec.NodeName gomega.Expect(nodeName).NotTo(gomega.BeEmpty(), "pod.Spec.NodeName must not be empty") <del> ginkgo.By(fmt.Sprintf("[init] waiting until the node=%s is not using the volume=%s", nodeName, pv.Name)) </del> <ins> // Snapshot tests are only executed for CSI drivers. When CSI drivers // are attached to the node they use VolumeHandle instead of the pv.Name. volumeName := pv.Spec.PersistentVolumeSource.CSI.VolumeHandle ginkgo.By(fmt.Sprintf("[init] waiting until the node=%s is not using the volume=%s", nodeName, volumeName)) </ins> success := storageutils.WaitUntil(framework.Poll, f.Timeouts.PVDelete, func() bool { node, err := cs.CoreV1().Nodes().Get(context.TODO(), nodeName, metav1.GetOptions{}) framework.ExpectNoError(err) volumesInUse := node.Status.VolumesInUse framework.Logf("current volumes in use: %+v", volumesInUse) for i := 0; i < len(volumesInUse); i++ { <del> if strings.HasSuffix(string(volumesInUse[i]), pv.Name) { </del> <ins> if strings.HasSuffix(string(volumesInUse[i]), volumeName) { </ins> return false } } return true }) framework.ExpectEqual(success, true) } cleanup := func() {
Change:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-crio-cgroupv1-node-e2e-conformance ContainerLogPath It was failing last week, then I disabled the SELinux while we investigated the issue Once this PR merges, I will enable the SELinux again for CRIO jobs. Once the SELinux is turned on and all the required components in the OS (e.g. crio, runc) are compiled with SELinux support we observed following errors in audit logs, Which points towards incorrect SELinux labeling.
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 node

Discussion:
import ( "context" v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/uuid"

Containers: []v1.Container{ { Image: busyboxImage, <del> Name:  podName, </del> <ins> SecurityContext: &v1.SecurityContext{ SELinuxOptions: &v1.SELinuxOptions{ Type: "container_logreader_t", }, }, Name: podName, </ins> // If we find expected log file and contains right content, exit 0 // else, keep checking until test timeout Command: []string{"sh", "-c", "while true; do if [ -e " + expectedLogPath + " ] && grep -q " + log + " " + expectedLogPath + "; then exit 0; fi; sleep 1; done"},
Change:
newer hostpath deployments but removed the csi-external-health-monitor-agent because it seemed to cause overhead without being needed for the tests. We should re-enable it and check whether that really causes tests to fail because of the extra load.
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 storage /area test

Discussion:
"github.com/onsi/ginkgo" "google.golang.org/grpc/codes" <del> appsv1 "k8s.io/api/apps/v1" </del> v1 "k8s.io/api/core/v1" rbacv1 "k8s.io/api/rbac/v1" storagev1 "k8s.io/api/storage/v1"

NodeName:                 node.Name, } cleanup, err := utils.CreateFromManifests(config.Framework, driverNamespace, func(item interface{}) error { <del> if err := utils.PatchCSIDeployment(config.Framework, o, item); err != nil { return err } // Remove csi-external-health-monitor-agent and // csi-external-health-monitor-controller // containers. They are not needed for any of the // tests and in practice apparently caused enough // overhead that even unrelated tests timed out. For // example, in the pull-kubernetes-e2e-kind test, 43 // out of 5771 tests failed, including tests from // sig-node, sig-cli, sig-api-machinery, sig-network. switch item := item.(type) { case *appsv1.StatefulSet: var containers []v1.Container for _, container := range item.Spec.Template.Spec.Containers { switch container.Name { case "csi-external-health-monitor-agent", "csi-external-health-monitor-controller": // Remove these containers. default: // Keep the others. containers = append(containers, container) } } item.Spec.Template.Spec.Containers = containers } return nil </del> <ins> return utils.PatchCSIDeployment(config.Framework, o, item) </ins> }, h.manifests...) if err != nil {
Change:
the following images are using old client-go that would not work correctly starting 1.22+ if those images use in-cluster config(mounted service account token) to talk to kube-apiserver: if the above images use in-cluster config, they should use client-go 1.14+. xref: /assign /cc /sig instrumentation /priority important-soon
/triage accepted

Discussion:
apiVersion: apps/v1 kind: Deployment metadata: <del> name: event-exporter-v0.3.1 </del> <ins> name: event-exporter-v0.3.4 </ins> namespace: kube-system labels: k8s-app: event-exporter <del> version: v0.3.1 </del> <ins> version: v0.3.4 </ins> kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile spec:

selector: matchLabels: k8s-app: event-exporter <del> version: v0.3.1 </del> <ins> version: v0.3.4 </ins> template: metadata: labels: k8s-app: event-exporter <del> version: v0.3.1 </del> <ins> version: v0.3.4 </ins> spec: serviceAccountName: event-exporter-sa containers: - name: event-exporter <del> image: k8s.gcr.io/event-exporter:v0.3.1 </del> <ins> image: gke.gcr.io/event-exporter:v0.3.4-gke.0 </ins> command: - /event-exporter - -sink-opts=-stackdriver-resource-model={{ exporter_sd_resource_model }} -endpoint={{ exporter_sd_endpoint }} # BEGIN_PROMETHEUS_TO_SD - name: prometheus-to-sd-exporter <del> image: k8s.gcr.io/prometheus-to-sd:v0.7.2 </del> <ins> image: gke.gcr.io/prometheus-to-sd:v0.11.1-gke.1 </ins> command: - /monitor - --stackdriver-prefix={{ prometheus_to_sd_prefix }}/addons

fi; # BEGIN_PROMETHEUS_TO_SD - name: prometheus-to-sd-exporter <del> image: k8s.gcr.io/prometheus-to-sd:v0.5.0 </del> <ins> image: k8s.gcr.io/prometheus-to-sd:v0.11.1 </ins> command: - /monitor - --stackdriver-prefix={{ prometheus_to_sd_prefix }}/addons

cpu: "30m" # BEGIN_PROMETHEUS_TO_SD - name: prometheus-to-sd-exporter <del> image: k8s.gcr.io/prometheus-to-sd:v0.5.0 </del> <ins> image: gke.gcr.io/prometheus-to-sd:v0.11.1-gke.1 </ins> # Request and limit resources to get guaranteed QoS. resources: requests:
Change:
The code block does these actions: the self-signed cert for loopback connection the loopbackClientConfig the self-signed cert to the If the main cert () is empty, the loopbackClientConfig will not be created due to this check, loopbackClientConfig shouldn't be left empty, because we have created the SNICert, it's just that we haven't executed action 3 to add the SNICert to the list. Switching the order of action 2 and action 3 will make the loopbackClientConfig successfully created. /kind bug /sig auth api-machinery

Discussion:
return fmt.Errorf("failed to generate self-signed certificate for loopback connection: %v", err) } <ins> // Write to the front of SNICerts so that this overrides any other certs with the same name (*secureServingInfo).SNICerts = append([]dynamiccertificates.SNICertKeyContentProvider{certProvider}, (*secureServingInfo).SNICerts...) </ins> secureLoopbackClientConfig, err := (*secureServingInfo).NewLoopbackClientConfig(uuid.New().String(), certPem) switch { // if we failed and there's no fallback loopback client config, we need to fail case err != nil && *loopbackClientConfig == nil: <ins> (*secureServingInfo).SNICerts = (*secureServingInfo).SNICerts[1:] </ins> return err // if we failed, but we already have a fallback loopback client config (usually insecure), allow it

default: *loopbackClientConfig = secureLoopbackClientConfig <del> // Write to the front of SNICerts so that this overrides any other certs with the same name (*secureServingInfo).SNICerts = append([]dynamiccertificates.SNICertKeyContentProvider{certProvider}, (*secureServingInfo).SNICerts...) </del> } return nil

<ins> /* Copyright 2021 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 options import ( "net" "testing" "k8s.io/apiserver/pkg/server" "k8s.io/client-go/rest" ) func TestEmptyMainCert(t *testing.T) { secureServingInfo := &server.SecureServingInfo{} var loopbackClientConfig *rest.Config s := (&SecureServingOptions{ BindAddress: net.ParseIP("127.0.0.1"), }).WithLoopback() ln, err := net.Listen("tcp", "127.0.0.1:0") if err != nil { t.Fatalf("failed to listen on 127.0.0.1:0") } defer ln.Close() s.Listener = ln s.BindPort = ln.Addr().(*net.TCPAddr).Port if err := s.ApplyTo(&secureServingInfo, &loopbackClientConfig); err != nil { t.Errorf("unexpected error: %v", err) } if loopbackClientConfig == nil { t.Errorf("unexpected empty loopbackClientConfig") } if e, a := 1, len(secureServingInfo.SNICerts); e != a { t.Errorf("expected %d SNICert, got %d", e, a) } } </ins>
Change:
As originally filed at BUG REPORT Passing to both and never actually creates or writes a log file whatever the level of and regardless of whether the enclosing directory exists. only works if the undocumented is passed as well. kubeadm version : Environment: Kubernetes version: Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Ubuntu 18.04.5 Kernel (e.g. ): 5.4.0 A log file to be produced at In this example fails to do anything when used with to join a node to the control plane. However, this issue persists across different subcommands.
/sig instrumentation
/assign I will try to reproduce it first
/triage accepted /assign /sig cloud-provider

Discussion:
kubeadmcmdoptions.KubeconfigDir, kubeadmcmdoptions.UploadCerts, kubeadmcmdoptions.Patches, <del> "print-join-command", "rootfs", "v") </del> <ins> "print-join-command", "rootfs", "v", "log-file") </ins> if allowedFlags.Has(flagName) { return true }
Change:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --kubelet-serial-gce-e2e-memory-manager no specific test, because the failure happens during waiting for the kubelet to come back after the restart the memory manager under the teardown, updates the kubelet configuration via dynamic configuration - because of the update, the kubelet health check is not responding for some short time period - e2e node service restart the kubelet - next memory manager test started and it stops the kubelet - the e2enode service fails on the initial health check - to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --
/sig node
/triage accepted

Discussion:
// update the kubelet config with old values updateKubeletConfig(f, oldCfg) <ins> // wait until the kubelet health check will pass and will continue to pass for specified period of time gomega.Eventually(func() bool { return kubeletHealthCheck(kubeletHealthCheckURL) }, time.Minute, 10*time.Second).Should(gomega.BeTrue()) gomega.Consistently(func() bool { return kubeletHealthCheck(kubeletHealthCheckURL) }, time.Minute, 10*time.Second).Should(gomega.BeTrue()) </ins> }) ginkgo.Context("with static policy", func() {
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 --Testgrid link: Reason for failure:
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
/assign /sig node

Discussion:
initialConfig.ShutdownGracePeriodCriticalPods = metav1.Duration{Duration: nodeShutdownGracePeriodCriticalPods} }) <ins> ginkgo.BeforeEach(func() { ginkgo.By("Wait for the node to be ready") waitForNodeReady() }) </ins> ginkgo.AfterEach(func() { ginkgo.By("Emitting Shutdown false signal; cancelling the shutdown") err := emitSignalPrepareForShutdown(false)
Change:
Originally post on project <!-- Thanks for helping us to improve K3S! We welcome all bug reports. Please fill out each area of the template so we can better help you. Comments like this will be hidden when you post but you can delete them if you wish. --Environmental Info: K3s Version: v1.21.0+k3s1 <!-- Provide the output from "k3s -v" --Node(s) CPU architecture, OS, and Version: Linux 4.19.0-16-cloud-amd64 SMP Debian 4.19.181-1 (2021-03-19) x86_64 <!-- Provide the output from "uname -a" on the node(s) --Cluster Configuration: 1 server & 3 agents <!-- Provide some basic information on the cluster configuration. For example, "3 servers, 2 agents". --Describe the bug: I use an external cloud controller manager to manage load balancing and services exposition. But on my services spec, I have no field but a instead. Everything works fine but server logs are flooded with entries like <!-- A clear and concise description of what the bug is. --Steps To Reproduce: <!-- Steps to reproduce the behavior. Please include as the first step how you installed K3s on the node(s) (including all flags or environment variables). If you have customized configuration via systemd drop-ins or overrides () please include those as well. --- Installed K3s: Use an external CCM which only provide a hostname to expose service Expected behavior: No more logs like <!-- A clear and concise description of what you expected to happen. --Actual behavior: Server logs are flooded with entries like <!-- A clear and concise description of what actually happened. --Additional context / logs: <!-- Add any other context and/or logs about the problem here. --Should it be a good idea to test consistency of IP here : or here ?
/sig cloud-provider
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /wg structured-logging 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 network
/assign
could you help to triage this issue? Since still have label
/triage accepted Seems like a missing check for ""

Discussion:
// Obtain Load Balancer Ingress IPs var ips []string for _, ing := range service.Status.LoadBalancer.Ingress { <del> ips = append(ips, ing.IP) </del> <ins> if ing.IP != "" { ips = append(ips, ing.IP) } </ins> } if len(ips) > 0 {
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 --I tried rebasing an old open PR, and got merge conflicts on api testdata. I read and tried the command listed there for regenerating the test data. It failed as follows. I expected successful regeneration of the api test data. Checkout and issue the command exhibited above. Kubernetes version (use ): is at commit right nowCloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/cc
ah, latest go versions changed the invocation to
fixed in
/triage accepted

Discussion:
kube::golang::setup_env <ins> # run in module mode to match test command in readme.md export GO111MODULE=on </ins> # UPDATE_COMPATIBILITY_FIXTURE_DATA=true regenerates fixture data if needed. # -run //HEAD only runs the test cases comparing against testdata for HEAD. # We suppress the output because we are expecting to have changes. # We suppress the test failure that occurs when there are changes. <del> UPDATE_COMPATIBILITY_FIXTURE_DATA=true go test ./vendor/k8s.io/api -run //HEAD >/dev/null 2>&1 || true </del> <ins> UPDATE_COMPATIBILITY_FIXTURE_DATA=true go test k8s.io/api -run //HEAD >/dev/null 2>&1 || true </ins> # Now that we have regenerated data at HEAD, run the test without suppressing output or failures <del> go test ./vendor/k8s.io/api -run //HEAD -count=1 </del> <ins> go test k8s.io/api -run //HEAD -count=1 </ins>

To run serialization tests just for the current version: ```sh <del> go test ./vendor/k8s.io/api -run //HEAD </del> <ins> go test k8s.io/api -run //HEAD </ins> ``` All three formats of a given group/version/kind are expected to decode successfully to identical objects,

Adding new fields or API types *is* expected to modify these fixtures. To regenerate them, run: ```sh <del> UPDATE_COMPATIBILITY_FIXTURE_DATA=true go test ./vendor/k8s.io/api -run //HEAD </del> <ins> UPDATE_COMPATIBILITY_FIXTURE_DATA=true go test k8s.io/api -run //HEAD </ins> ``` ## Previous versions

To run serialization tests just for a previous version, like `v1.14.0`: ```sh <del> go test ./vendor/k8s.io/api -run //v1.14.0 </del> <ins> go test k8s.io/api -run //v1.14.0 </ins> ``` To run serialization tests for a particular group/version/kind, like `apps/v1` `Deployment`: ```sh <del> go test ./vendor/k8s.io/api -run /apps.v1.Deployment/ </del> <ins> go test k8s.io/api -run /apps.v1.Deployment/ </ins> ``` Failures to decode, to round-trip identical bytes, or to decode identical objects from json/yaml/protobuf,
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 --Docker is always installed on node boot which adds significant start time and adds software that's unnecessary. containerd Windows nodes should not have Docker installed. Start a Kubernetes GCE Windows cluster via kube-up. You can run stuff like on it. 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 windows /triage accepted

Discussion:
function set-windows-node-image() { WINDOWS_NODE_IMAGE_PROJECT="windows-cloud" if [[ "${WINDOWS_NODE_OS_DISTRIBUTION}" == "win2019" ]]; then <del> WINDOWS_NODE_IMAGE="windows-server-2019-dc-core-v20210112" </del> <ins> WINDOWS_NODE_IMAGE="windows-server-2019-dc-core-v20210413" </ins> elif [[ "${WINDOWS_NODE_OS_DISTRIBUTION}" == "win1909" ]]; then <del> WINDOWS_NODE_IMAGE="windows-server-1909-dc-core-v20210112" </del> <ins> WINDOWS_NODE_IMAGE="windows-server-1909-dc-core-v20210413" </ins> elif [[ "${WINDOWS_NODE_OS_DISTRIBUTION}" == "win2004" ]]; then <del> WINDOWS_NODE_IMAGE="windows-server-2004-dc-core-v20210112" </del> <ins> WINDOWS_NODE_IMAGE="windows-server-2004-dc-core-v20210413" </ins> elif [[ "${WINDOWS_NODE_OS_DISTRIBUTION,,}" == "win20h2" ]]; then <del> WINDOWS_NODE_IMAGE="windows-server-20h2-dc-core-v20210112" </del> <ins> WINDOWS_NODE_IMAGE="windows-server-20h2-dc-core-v20210413" </ins> else echo "Unknown WINDOWS_NODE_OS_DISTRIBUTION ${WINDOWS_NODE_OS_DISTRIBUTION}" >&2 exit 1

exit 0 } <del> if (-not (Test-DockerIsInstalled)) { Install-Docker } # For some reason the docker service may not be started automatically on the # first reboot, although it seems to work fine on subsequent reboots. Restart-Service docker Start-Sleep 5 if (-not (Test-DockerIsRunning)) { throw "docker service failed to start or stay running" </del> <ins> $kube_env = Fetch-KubeEnv Set-EnvironmentVars # Install Docker if the select CRI is not containerd and docker is not already # installed. if (${env:CONTAINER_RUNTIME} -ne "containerd") { if (-not (Test-DockerIsInstalled)) { Install-Docker } # For some reason the docker service may not be started automatically on the # first reboot, although it seems to work fine on subsequent reboots. Restart-Service docker Start-Sleep 5 if (-not (Test-DockerIsRunning)) { throw "docker service failed to start or stay running" } </ins> } Set-PrerequisiteOptions <del> $kube_env = Fetch-KubeEnv </del> if (Test-IsTestCluster $kube_env) { Log-Output 'Test cluster detected, installing OpenSSH.'

StartProcess-WriteSshKeys } <del> Set-EnvironmentVars </del> Create-Directories Download-HelperScripts
Change:
prints no error message with zero exit code even with invalid command option. e.g. --from-file=<non-existing-pathprints error message with non-zero exit code. Please try following command. It does not print any error and exit code is . will fix this issue.
/sig cli
/triage accepted

Discussion:
func (o *ConfigMapOptions) Run() error { configMap, err := o.createConfigMap() if err != nil { <del> return nil </del> <ins> return err </ins> } if err := util.CreateOrUpdateAnnotation(o.CreateAnnotation, configMap, scheme.DefaultJSONEncoder()); err != nil { return err