jiebi/CodeConvo huggingface dataset:
Change:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): statusFailure Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): 4 Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: Others What happened: In FlexVolume code: The statusFailure constant should have string literal "Failure", not "Failed". Because in the test code or documentation everywhere, only "Failure" string is used, not "Failed" for the flexvolume cmd output status string. So this is a typo bug. Here is the test: here is the documentation: here is the example: What you expected to happen: The statusFailure constant should have string literal "Failure", not "Failed" at this line: How to reproduce it (as minimally and precisely as possible): code inspect: Anything else do we need to know: nothing else

Discussion:
const ( // StatusSuccess represents the successful completion of command. StatusSuccess = "Success" <del> // StatusFailed represents that the command failed. StatusFailure = "Failed" </del> // StatusNotSupported represents that the command is not supported. StatusNotSupported = "Not supported" )
Change:
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment}
did you see this failure by any chance while working on
No. I didn't see that one.
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment}
Found it. Opened
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment}
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment}
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment}
Running this test 8 times in a loop on my workstation, I was able to get a reliable failure signal.
This is still failing. Please take a look into

Discussion:
f.t.Errorf("error syncing deployment: %v", err) } <del> actions := f.client.Actions() </del> <ins> actions := filterInformerActions(f.client.Actions()) </ins> informerActions := 0 for i, action := range actions { <del> if len(action.GetNamespace()) == 0 && (action.Matches("list", "pods") || action.Matches("list", "replicasets") || action.Matches("list", "deployments") || action.Matches("watch", "pods") || action.Matches("watch", "replicasets") || action.Matches("watch", "deployments")) { informerActions++ continue } </del> if len(f.actions)+informerActions < i+1 { f.t.Errorf("%d unexpected actions: %+v", len(actions)-len(f.actions), actions[i:]) break

if len(fake.Actions()) == 0 { return } <del> for _, action := range fake.Actions() { </del> <ins> for _, action := range filterInformerActions(fake.Actions()) { </ins> t.Logf("unexpected action: %#v", action) } t.Errorf("expected deployment controller to not take action") } <ins> func filterInformerActions(actions []core.Action) []core.Action { ret := []core.Action{} for _, action := range actions { if len(action.GetNamespace()) == 0 && (action.Matches("list", "pods") || action.Matches("list", "deployments") || action.Matches("list", "replicasets") || action.Matches("watch", "pods") || action.Matches("watch", "deployments") || action.Matches("watch", "replicasets")) { continue } ret = append(ret, action) } return ret } </ins>
Change:
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment} Previous issues for this test:
I hit it too, direct link to build: https://k8s- PR here:
: can you try rebasing on ? That should have fixed this problem
Looks like they finally passed and retest is skipped for the submit-queue for that PR, so I'd prefer not to rebase and risk encountering another flake. If you need it as a confirmation of , let me know and I'll force push my rebase.
no worries. things are looking up in the gate. we can close this issue out tomorrow
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment}
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment}
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment}
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment}
This is still happening and blocking the build. please treat this as a real P0.
https://k8s- Failed: TestDeploymentController_dontSyncDeploymentsWithEmptyPodSelector {deployment}
cc
opened

Discussion:
} actions := filterInformerActions(f.client.Actions()) <del> informerActions := 0 </del> for i, action := range actions { <del> if len(f.actions)+informerActions < i+1 { </del> <ins> if len(f.actions) < i+1 { </ins> f.t.Errorf("%d unexpected actions: %+v", len(actions)-len(f.actions), actions[i:]) break } <del> expectedAction := f.actions[i-informerActions] </del> <ins> expectedAction := f.actions[i] </ins> if !expectedAction.Matches(action.GetVerb(), action.GetResource().Resource) { f.t.Errorf("Expectednt%#vngotnt%#v", expectedAction, action) continue

// We expect the deployment controller to not take action here since it's configuration // is invalid, even though no replicasets exist that match it's selector. controller.syncDeployment(fmt.Sprintf("%s/%s", d.ObjectMeta.Namespace, d.ObjectMeta.Name)) <del> if len(fake.Actions()) == 0 { </del> <ins> filteredActions := filterInformerActions(fake.Actions()) if len(filteredActions) == 0 { </ins> return } <del> for _, action := range filterInformerActions(fake.Actions()) { </del> <ins> for _, action := range filteredActions { </ins> t.Logf("unexpected action: %#v", action) } t.Errorf("expected deployment controller to not take action")
Change:
Sometimes e2e tests fails during cluster installation because curl fails with: For example see here: https://k8s- Downloading etcd failed. I've run curl to get etcd from github 4400 times. It failed 5 times. So it doesn't happen often.

Discussion:
cd "${KUBE_ROOT}/third_party" if [[ $(uname) == "Darwin" ]]; then download_file="etcd-v${ETCD_VERSION}-darwin-amd64.zip" <del> curl -fsSLO --retry 3 --keepalive-time 2 https://github.com/coreos/etcd/releases/download/v${ETCD_VERSION}/"${download_file}" </del> <ins> url="https://github.com/coreos/etcd/releases/download/v${ETCD_VERSION}/${download_file}" kube::util::download_file "${url}" "${download_file}" </ins> unzip -o "${download_file}" ln -fns "etcd-v${ETCD_VERSION}-darwin-amd64" etcd rm "${download_file}" else <del> curl -fsSL --retry 3 --keepalive-time 2 https://github.com/coreos/etcd/releases/download/v${ETCD_VERSION}/etcd-v${ETCD_VERSION}-linux-amd64.tar.gz | tar xzf - </del> <ins> url="https://github.com/coreos/etcd/releases/download/v${ETCD_VERSION}/etcd-v${ETCD_VERSION}-linux-amd64.tar.gz" download_file="etcd-v${ETCD_VERSION}-linux-amd64.tar.gz" kube::util::download_file "${url}" "${download_file}" tar xzf "${download_file}" </ins> ln -fns "etcd-v${ETCD_VERSION}-linux-amd64" etcd fi kube::log::info "etcd v${ETCD_VERSION} installed. To use:"

return 1 } <ins> kube::util::download_file() { local -r url=$1 local -r destination_file=$2 rm  ${destination_file} 2&> /dev/null || true for i in $(seq 5) do if ! curl -fsSL --retry 3 --keepalive-time 2 ${url} -o ${destination_file}; then echo "Downloading ${url} failed. $((5-i)) retries left." sleep 1 else echo "Downloading ${url} succeed" return 0 fi done return 1 } </ins> # ex: ts=2 sw=2 et filetype=sh
Change:
While running kubemark tests we are facing "no space left on device" problems, because master-disk is not mounted in kubemark.
I'm reopening it for now, since it seems that we are still facing "no space left on device" issues in kubemark scale.
Seems to be fixed by

Discussion:
TEST_ETCD_VERSION="2.2.1" fi <del> retry() { </del> <ins> function retry() { </ins> for i in {1..4}; do "$@" && return 0 || sleep $i done "$@" } <ins> function mount-master-pd() { if [[ ! -e /dev/disk/by-id/google-master-pd ]]; then echo "Can't find master-pd. Skipping mount." return fi device_info=$(ls -l "/dev/disk/by-id/google-master-pd") relative_path=${device_info##* } pd_device="/dev/disk/by-id/${relative_path}" echo "Mounting master-pd" local -r pd_path="/dev/disk/by-id/google-master-pd" local -r mount_point="/mnt/disks/master-pd" # Format and mount the disk, create directories on it for all of the master's # persistent data, and link them to where they're used. mkdir -p "${mount_point}" device=$1 mountpoint=$2 # Format only if the disk is not already formatted. if ! tune2fs -l "${pd_path}" ; then echo "Formatting '${pd_path}'" mkfs.ext4 -F -E lazy_itable_init=0,lazy_journal_init=0,discard "${pd_path}" fi mkdir -p "${mount_point}" echo "Mounting '${pd_path}' at '${mount_point}'" mount -o discard,defaults "${pd_path}" "${mount_point}" echo "Mounted master-pd '${pd_path}' at '${mount_point}'" # Contains all the data stored in etcd. mkdir -m 700 -p "${mount_point}/var/etcd" ln -s -f "${mount_point}/var/etcd" /var/etcd mkdir -p /etc/srv # Contains the dynamically generated apiserver auth certs and keys. mkdir -p "${mount_point}/srv/kubernetes" ln -s -f "${mount_point}/srv/kubernetes" /etc/srv/kubernetes # Directory for kube-apiserver to store SSH key (if necessary). mkdir -p "${mount_point}/srv/sshproxy" ln -s -f "${mount_point}/srv/sshproxy" /etc/srv/sshproxy if ! id etcd &>/dev/null; then useradd -s /sbin/nologin -d /var/etcd etcd fi } </ins> if [ "${EVENT_STORE_IP}" == "127.0.0.1" ]; then # Retry starting etcd to avoid pulling image errors. retry sudo docker run --net=host 

# Increase the allowed number of open file descriptors ulimit -n 65536 <ins> mount-master-pd </ins> tar xzf kubernetes-server-linux-amd64.tar.gz kubernetes/server/bin/kube-scheduler --master=127.0.0.1:8080 $(cat scheduler_flags) &> /var/log/kube-scheduler.log &
Change:
kubectl create service loadbalancer --help Create a LoadBalancer service with the specified name. Examples: # Create a new nodeport service named my-lbs kubectl create service loadbalancer my-lbs --tcp=5678:8080 $ kubectl version Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-09-26T18:16:57Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-10-16T06:20:04Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

Discussion:
Create a LoadBalancer service with the specified name.`) serviceLoadBalancerExample = templates.Examples(` <del> # Create a new nodeport service named my-lbs </del> <ins> # Create a new LoadBalancer service named my-lbs </ins> kubectl create service loadbalancer my-lbs --tcp=5678:8080`) )
Change:
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

Discussion:
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 {
Change:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): bug Kubernetes version (use ): master What happened: is printed when error. What you expected to happen: Only error message was printed.
I believed this has been fixed
, it seems not; in , it's not necessary to print if errs is not empty. Refer to the PR on the proposal :).
ok, seems other issue.

Discussion:
} errs = append(errs, err) } <del> if len(infos) == 0 { </del> <ins> if len(infos) == 0 && len(errs) == 0 { </ins> outputEmptyListWarning(errOut) }

if err != nil { allErrs = append(allErrs, err) } <del> if len(infos) == 0 { </del> <ins> if len(infos) == 0 && len(allErrs) == 0 { </ins> outputEmptyListWarning(errOut) }
Change:
https://k8s- Failed: [] Cluster size autoscaling [Slow] should increase cluster size if pods are pending due to host port conflict [Feature:ClusterSizeAutoscalingScaleUp] {Kubernetes e2e suite} Previous issues for this test:
The trouble here is that the pods are in , from the controller-manager logs:
I believe the problem here is that pods are sneaking onto machines and then not starting due to constraints (host port unavailable) but these pods count as which causes the test to go forever. I'm going to switch the test to only consider pods.

Discussion:
ready = true } } <del> if !ready { </del> <ins> // Failed pods in this context generally mean that they have been // double scheduled onto a node, but then failed a constraint check. if pod.Status.Phase == api.PodFailed { glog.Warningf("Pod has failed: %v", pod) } if !ready && pod.Status.Phase != api.PodFailed { </ins> notready = append(notready, pod.Name) } }
Change:
FYI
this should be a pretty simple thing to fix, if you have the time?
I am able to send a quick fix by EOD.

Discussion:
Ports: []v1.ServicePort{ { Name:       "http", <ins> Protocol:   v1.ProtocolTCP, </ins> Port:       80, TargetPort: intstr.FromInt(8080), }, }, <ins> SessionAffinity: v1.ServiceAffinityNone, </ins> }, } By(fmt.Sprintf("Trying to create service %q in namespace %q", service.Name, namespace))
Change:
Problem Running the e2e density tests on a local cluster or any other cluster where ssh to master doesn't work fails, even though enough pods are created, because of SSH attempts. Specifically "should allow starting 30" is the argument to reproduce. Solution Allow density tests to pass even if some meta test operations fail after the fact. cc

Discussion:
// Verify scheduler metrics. // TODO: Reset metrics at the beginning of the test. // We should do something similar to how we do it for APIserver. <del> framework.ExpectNoError(framework.VerifySchedulerLatency(c)) </del> <ins> if err = framework.VerifySchedulerLatency(c); err != nil { framework.Logf("Warning: Scheduler latency not calculated, %v", err) } </ins> }) // Explicitly put here, to delete namespace at the end of the test
Change:
https://k8s- Failed: [] Job should run a job to completion when tasks sometimes fail and are not locally restarted {Kubernetes e2e suite} Previous issues for this test:
Meta issue:
This is not a problem with that particular test but a general problem mentioned in . Closing in favor of that.
/reopen this job seems to be one of the flakiest sig-apps jobs, both on and .
you can't re-open an issue/PR unless you authored it or you are assigned to it. <detailsIn response to : /reopen </details
/remove-priority backlog /priority important-soon
I'm hoping to get to this flake later this week, or Monday next week at latest.

Discussion:
// Worst case analysis: 15 failures, each taking 1 minute to // run due to some slowness, 1 in 2^15 chance of happening, // causing test flake.  Should be very rare. <del> job := framework.NewTestJob("randomlySucceedOrFail", "rand-non-local", v1.RestartPolicyNever, parallelism, completions, nil, backoffLimit) </del> <ins> job := framework.NewTestJob("randomlySucceedOrFail", "rand-non-local", v1.RestartPolicyNever, parallelism, completions, nil, 999) </ins> job, err := framework.CreateJob(f.ClientSet, f.Namespace.Name, job) Expect(err).NotTo(HaveOccurred())
Change:
Either deprecate the nsenter exec handler, or add nsenter handling to the dockershim (after goes in). /cc
I vote for deprecating the nsenter exec handler for docker. has been the default exec handler since kubernetes pre-1.0. Is there any reason (or use case) for keeping the pluggable exec handler? Another question is that whether we can drop exec in one release, or we need to provide support in CRI for at lease one more release. /cc
+1 for docker exec.
I suggest deprecating docker nsenter exec in a long term, but to achieve that, we need to follow the deprecation policy. The first thing we need to address is marking this flag (--docker-exec-handler, default: native) being deprecated:
Also there are several issues raised before which are related to the issue of docker exec in various versions. The engineer even suggested to switch the default mechanism is docker nsenter exec. One of the examples is
Now let's narrow down to the CRI scope, and below is my 2 cents: 1) Can we mark the flag deprecated in 1.6? 2) Drop the support in CRI in 1.6? Inform the kubernetes users with this decision along CRI announcement being scheduled sometimes in February? 3) Drop the support completely from Kubernetes unless there are real use cases coming up.
We'll have to tell the users that they need to disable CRI in order to use the nsenter exec plugin. could you give a quick estimate about the amount of work required to add support for nsenter exec in dockershim? Thanks.
Talked to offline. I'll Add support nsenter as exec in dockershim Mark the flag as deprecated.

Discussion:
// NOTE: Anything passed to DockerService should be eventually handled in another way when we switch to running the shim as a different process. func NewDockerService(client dockertools.DockerInterface, seccompProfileRoot string, podSandboxImage string, streamingConfig *streaming.Config, <del> pluginSettings *NetworkPluginSettings, cgroupsName string, kubeCgroupDriver string) (DockerService, error) { </del> <ins> pluginSettings *NetworkPluginSettings, cgroupsName string, kubeCgroupDriver string, execHandler dockertools.ExecHandler) (DockerService, error) { </ins> c := dockertools.NewInstrumentedDockerInterface(client) ds := &dockerService{ seccompProfileRoot: seccompProfileRoot,

os:                 kubecontainer.RealOS{}, podSandboxImage:    podSandboxImage, streamingRuntime: &streamingRuntime{ <del> client: client, // Only the native exec handling is supported for now. // TODO(#35747) - Either deprecate nsenter exec handling, or add support for it here. execHandler: &dockertools.NativeExecHandler{}, </del> <ins> client:      client, execHandler: execHandler, </ins> }, containerManager: cm.NewContainerManager(cgroupsName, client), }

streamingConfig := getStreamingConfig(kubeCfg, kubeDeps) // Use the new CRI shim for docker. ds, err := dockershim.NewDockerService(klet.dockerClient, kubeCfg.SeccompProfileRoot, kubeCfg.PodInfraContainerImage, <del> streamingConfig, &pluginSettings, kubeCfg.RuntimeCgroups, kubeCfg.CgroupDriver) </del> <ins> streamingConfig, &pluginSettings, kubeCfg.RuntimeCgroups, kubeCfg.CgroupDriver, dockerExecHandler) </ins> if err != nil { return nil, err }
Change:
Addon Manager was broken a few times recently by some indirect-related changes(like ) made in the code base. Addon Manager's logs would be very helpful for narrowing down the problem. And I don't think there is an obvious way to retrieve Addon Manager's logs for Jenkins tests currently. This can be achieved in the same way as what we did for the components like and (mounting /var/log). I will try it through this way for addon manager. cc

Discussion:
readonly master_ssh_supported_providers="gce aws kubemark" readonly node_ssh_supported_providers="gce gke aws" <del> readonly master_logfiles="kube-apiserver kube-scheduler rescheduler kube-controller-manager etcd glbc cluster-autoscaler" </del> <ins> readonly master_logfiles="kube-apiserver kube-scheduler rescheduler kube-controller-manager etcd glbc cluster-autoscaler kube-addon-manager" </ins> readonly node_logfiles="kube-proxy" readonly aws_logfiles="cloud-init-output" readonly gce_logfiles="startupscript"

- name: kube-addon-manager # When updating version also bump it in cluster/images/hyperkube/static-pods/addon-manager.json image: gcr.io/google-containers/kube-addon-manager:v5.2 <ins> command: - /bin/bash - -c - /opt/kube-addons.sh 1>>/var/log/kube-addon-manager.log 2>&1 </ins> resources: requests: cpu: 5m

- mountPath: /etc/kubernetes/ name: addons readOnly: true <ins> - mountPath: /var/log name: varlog readOnly: false </ins> volumes: - hostPath: path: /etc/kubernetes/ name: addons <ins> - hostPath: path: /var/log name: varlog </ins>
Change:
Seen in issue Logs from : At the very least, we should retry godep restore a couple times given the heavy network dependencies it has. The network dependencies are sorta necessary... but they change rarely so we could also do some clever caching of unmodified clones that we put in place ahead of time to dodge network traffic outside of new deps being . cc
We could probably do a single retry and avoid most flakes. Godep restore takes a long time though, so if we retry too many times we'll run into timeout issues (but maybe that's fine). See also , tools/godep
Actually, it looks like this is only being done for an excluded verify step (). We should not do this for an excluded step, and we should not do for every PR.
can you explain why staging/ needs to function?
verify- also runs :
eventually gets published to . IIRC, it needs because otherwise a later fails ().
If we can run the verify script in order, then we can run verify-staging-client- after verify-, then we can save one .
verify- exits out early if Godeps/ or vendor/ hasn't changed.
Hmm, ok. How often will fail?
I'm seeing ~.5% failure rate over the last few days, and averaging ~2 minutes for the godep restore. Do we have to check in _vendor for the staging client code at all?
We run to find all the dependencies of clients, including k8s packages, so _vendor is not the reason we need .

Discussion:
cd /go/src/k8s.io/kubernetes # hack/verify-client-go.sh requires all dependencies exist in the GOPATH. <del> godep restore </del> <ins> # the retry helps avoid flakes while keeping total time bounded. godep restore || godep restore </ins> ./hack/install-etcd.sh make verify