jiebi/CodeConvo huggingface dataset:
Code change:
pod.Annotations[podcmd.DefaultContainerAnnotationName] = name return pod } <ins> func TestReattachMessage(t *testing.T) { tests := []struct { name          string pod           *corev1.Pod rawTTY, stdin bool container     string expected      string }{ { name:      "normal interactive session", pod:       attachPod(), container: "bar", rawTTY:    true, stdin:     true, expected:  "Session ended, resume using", }, { name:      "no stdin", pod:       attachPod(), container: "bar", rawTTY:    true, stdin:     false, expected:  "", }, { name:      "not connected to a real TTY", pod:       attachPod(), container: "bar", rawTTY:    false, stdin:     true, expected:  "", }, { name: "no restarts", pod: &corev1.Pod{ ObjectMeta: metav1.ObjectMeta{Name: "foo", Namespace: "test"}, Spec: corev1.PodSpec{ RestartPolicy: corev1.RestartPolicyNever, Containers:    []corev1.Container{{Name: "bar"}}, }, Status: corev1.PodStatus{Phase: corev1.PodRunning}, }, container: "bar", rawTTY:    true, stdin:     true, expected:  "", }, { name:      "ephemeral container", pod:       attachPod(), container: "debugger", rawTTY:    true, stdin:     true, expected:  "Session ended, the ephemeral container will not be restarted", }, } for _, test := range tests { t.Run(test.name, func(t *testing.T) { options := &AttachOptions{ StreamOptions: exec.StreamOptions{ Stdin: test.stdin, }, Pod: test.pod, } if msg := options.reattachMessage(test.container, test.rawTTY); test.expected == "" && msg != "" { t.Errorf("reattachMessage(%v, %v) = %q, want empty string", test.container, test.rawTTY, msg) } else if !strings.Contains(msg, test.expected) { t.Errorf("reattachMessage(%v, %v) = %q, want string containing %q", test.container, test.rawTTY, msg, test.expected) } }) } } </ins>

Related discussion:
text: When attaching to an ephemeral container, prints a message suggesting that the container can be reattached after it exists. This is not true because an ephemeral container is never restarted. This cosmetic issue should be resolved for
/assign /sig node /triage accepted /priority important-longterm
Code change:
}) Describe("container runtime conformance blackbox test", func() { <del> var testCContainers []ConformanceContainer </del> namespace := "runtime-conformance" <del> BeforeEach(func() { testCContainers = []ConformanceContainer{} }) Context("when start a container that exits successfully", func() { </del> <ins> Context("when starting a container that exits", func() { </ins> It("it should run with the expected status [Conformance]", func() { <ins> restartCountVolumeName := "restart-count" restartCountVolumePath := "/restart-count" </ins> testContainer := api.Container{ Image: ImageRegistry[busyBoxImage], VolumeMounts: []api.VolumeMount{ { <del> MountPath: "/restart-count", Name:      "restart-count", </del> <ins> MountPath: restartCountVolumePath, Name:      restartCountVolumeName, </ins> }, }, <del> ImagePullPolicy: api.PullIfNotPresent, </del> } testVolumes := []api.Volume{ { <del> Name: "restart-count", </del> <ins> Name: restartCountVolumeName, </ins> VolumeSource: api.VolumeSource{ HostPath: &api.HostPathVolumeSource{ Path: os.TempDir(),

Related discussion:
text: Slow conformance test has caused issues like We should make runtime/image conformance test run faster without breaking the test coverage, possibly by: Shorten consistently check interval . Remove redundant test cases such as ... /cc
Code change:
// test pods from running, and tests that ensure all pods are running and // ready will fail). if err := waitForPodsRunningReady(api.NamespaceDefault, testContext.MinStartupPods, podStartupTimeout); err != nil { <del> glog.Fatalf("Error waiting for all pods to be running and ready: %v", err) </del> <ins> t.Errorf("Error waiting for all pods to be running and ready: %v", err) return </ins> } // Run tests through the Ginkgo runner with output to console + JUnit for Jenkins var r []ginkgo.Reporter if *reportDir != "" { r = append(r, reporters.NewJUnitReporter(path.Join(*reportDir, fmt.Sprintf("junit_%02d.xml", config.GinkgoConfig.ParallelNode)))) <del> failReport := &failReporter{} r = append(r, failReport) defer func() { if failReport.failed { coreDump(*reportDir) } }() </del> } ginkgo.RunSpecsWithDefaultAndCustomReporters(t, "Kubernetes e2e suite", r) }

Related discussion:
text: We for uploading to GCS on , but not on successful e2e runs or failed test -up. We should definitely be dumping those logs for failed cluster-ups, and it would also be nice to throw in the successes too (good to have recent green for comparison).
Getting logs uploaded on a failed test -up seems really important for debugging.
+1 There were just a bunch of failures in scalability test suite (run 1623-1628) that failed because not all system pods were running. Since there are no logs, there is no easy way to debug it. It would be super useful to have all the logs for failed cluster-ups. cc
Unless I'm confused, it looks as if these logs are still not being uploaded. FYI.
For example: gs://kubernetes-jenkins/logs/kubernetes-e2e-gce/7500
That particular build was a timeout. When Jenkins kills the job, the log-collecting code never runs.
Another case we won't collect logs is if the cluster fails to initialize. (Which is a really important place to collect logs, but it's not a trivial fix.)
Moving this into post, since it seems unlikely to get fixed in the near term. feel free to correct me if I'm wrong.
We also don't collect logs on test job timeouts, which is frustrating.
+1
will collect the logs when the cluster fails to initialize. That's not all the cases listed here, but it's a good one.
I'd like to bump the priority for this further - we don't have any logs to help with debugging , which started to happen more often recently - it seems that didn't help. cc
I have too many P0s assigned to me already. This is at least 3rd in line right now.
This one is half year old and is P0 for a month...
From discussion with on hangouts, a vague plan: move log-dumping logic from into a standalone command in something like (feel free to bikeshed the name) update Jenkins to call this command as a post-build step probably remove and the debug stuff recently to . Right now the stuff is pretty GCE/GKE specific and uses ssh. We should probably change to a more provider-agnostic method, but this would be a good start.
Hm, actually, post-build step actually won't work, since we tear down the cluster first.
Code change:
// test pods from running, and tests that ensure all pods are running and // ready will fail). if err := waitForPodsRunningReady(api.NamespaceDefault, testContext.MinStartupPods, podStartupTimeout); err != nil { <del> glog.Fatalf("Error waiting for all pods to be running and ready: %v", err) </del> <ins> t.Errorf("Error waiting for all pods to be running and ready: %v", err) return </ins> } // Run tests through the Ginkgo runner with output to console + JUnit for Jenkins var r []ginkgo.Reporter if *reportDir != "" { r = append(r, reporters.NewJUnitReporter(path.Join(*reportDir, fmt.Sprintf("junit_%02d.xml", config.GinkgoConfig.ParallelNode)))) <del> failReport := &failReporter{} r = append(r, failReport) defer func() { if failReport.failed { coreDump(*reportDir) } }() </del> } ginkgo.RunSpecsWithDefaultAndCustomReporters(t, "Kubernetes e2e suite", r) }

Related discussion:
text: But making it a separate command can still let us call it in more places.
FYI - we also need logs from timed-out runs (not only the failed ones).
moving out into its own binary should help accomplish this.
I'm worried that the best way to do this is to write a bash script that grabs IPs from 's and functions and just does an ssh and cats the logs. Then we could point at that. It's sorta difficult to make work on its own.
I think at this point we're happy with anything that usually works. We can work on making in nice and shiny later.
We now get logs when kube-up fails, which recently happened :) Still some work to do here, I'll leave this issue open until timeouts are handled properly and points here.
- I can't thank you enough!
Ok, is in so we should get logs for kubernetes-e2e-* jobs and PR Jenkins jobs on timeout.
I'm gonna call this done.
Code change:
return "", err } <del> // If the volumeMode is 'Block', plugin don't have to format the volume. // The globalPDPath will be created by operationexecutor. Just return devicePath here. klog.V(5).Infof("fc: AttachDisk volumeMode: %s, devicePath: %s", b.volumeMode, devicePath) if b.volumeMode == v1.PersistentVolumeBlock { return devicePath, nil } // mount it globalPDPath := util.MakeGlobalPDName(*b.fcDisk) if err := os.MkdirAll(globalPDPath, 0750); err != nil { return devicePath, fmt.Errorf("fc: failed to mkdir %s, error", globalPDPath) } noMnt, err := b.mounter.IsLikelyNotMountPoint(globalPDPath) if err != nil { return devicePath, fmt.Errorf("Heuristic determination of mount point failed:%v", err) } if !noMnt { klog.Infof("fc: %s already mounted", globalPDPath) return devicePath, nil } err = b.mounter.FormatAndMount(devicePath, globalPDPath, b.fsType, b.mountOptions) if err != nil { return devicePath, fmt.Errorf("fc: failed to mount fc volume %s [%s] to %s, error %v", devicePath, b.fsType, globalPDPath, err) } return devicePath, err </del> <ins> return devicePath, nil </ins> } // DetachDisk removes scsi device file such as /dev/sdX from the node.

Related discussion:
text: What happened: An iSCSI PV with is mounted without these options. What you expected to happen: The volume is mounted with . Anything else we need to know?: iSCSI volume is mounted in and passes as : This can be fixed trivially, however, why is it mounted in at all? There is another mount attempt in , with correct mount options: This code is skipped, because the volume is already mounted. Environment: Kubernetes version (use ): today's master, v1.19.0-alpha.0.781+-dirty , do you remember why we mount stuff in ? iSCSI and FibreChannel does so, the others don't.
/sig storage
Code change:
err = wait.PollImmediate(dsRetryPeriod, dsRetryTimeout, checkRunningOnAllNodes(f, ds)) Expect(err).NotTo(HaveOccurred(), "error waiting for daemon pod to start") <del> By(fmt.Sprintf("Make sure all daemon pods have correct template generation %d", templateGeneration)) err = checkDaemonPodsTemplateGeneration(c, ns, label, fmt.Sprint(templateGeneration)) Expect(err).NotTo(HaveOccurred()) </del> // Check history and labels ds, err = c.AppsV1().DaemonSets(ns).Get(ds.Name, metav1.GetOptions{}) Expect(err).NotTo(HaveOccurred())

Related discussion:
text: Please see : https://k8s- fails just after this line: Failure was introduced in: But this was not noticed until it started running in [Conformance] tests. You can see the same problem in other dashboards too: https://k8s- https://k8s-
cc /sig apps
/priority critical-urgent
/kind bug /priority failing-test
/milestone v1.10
Is this just an oversight of not removing the template generation when the API update was done?
/cc
triaged in progress
i have never touched this test before ... so i just threw in a WIP, feel free to use/discard it. there seems to be lot of methods in there that is no longer used, may be we can rip those out too. (see )
xref
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action Required: This issue has not been updated since Mar 5. Please provide an update. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Code change:
Image:   imageutils.GetE2EImage(imageutils.BusyBox), Command: []string{"sh", "-c"}, Args: []string{` <ins> sleep 9999999 & PID=$! </ins> _term() { <ins> kill $PID </ins> echo "Caught SIGTERM signal!" <del> exit 0 </del> } trap _term SIGTERM <del> while true; do sleep 5; done </del> <ins> wait $PID exit 0 </ins> `, }, },

Related discussion:
text: Followup feedback from In a few e2e node tests (e.g. tests of deletion grace period) we have some busybox pods that wait for SIGTERM and perform some action like a small sleep to simulate SIGTERM taking some time. These tests follow the pattern of -- see The will block the SIGTERM handler from being run until after the time is elapsed. We should consider to remove the and instead use to avoid blocking the SIGTERM handler, see pattern followed in n/a n/a No response n/a n/a <details</details<details</details<details</details<details</details
/sig node /cc
/assign
/triage accepted
Code change:
Description: The Pod with toleration timeout scheduled on a tainted Node MUST not be evicted if the taint is removed before toleration time ends. */ <del> framework.ConformanceIt("removing taint cancels eviction", func() { </del> <ins> framework.ConformanceIt("removing taint cancels eviction [Disruptive]", func() { </ins> podName := "taint-eviction-4" pod := createPodForTaintsTest(true, 2*additionalWaitPerDeleteSeconds, podName, podName, ns) observedDeletions := make(chan string, 100)

Related discussion:
text: What would you like to be : Our tooling that makes the list of conformance tests needs to allow conformance tests to be marked as disruptive. Why is this needed: To test default, conformance behavior which may be disruptive (e.g. taint eviction) ref /sig testing /area conformance
Code change:
Description: The Pod with toleration timeout scheduled on a tainted Node MUST not be evicted if the taint is removed before toleration time ends. */ <del> framework.ConformanceIt("removing taint cancels eviction", func() { </del> <ins> framework.ConformanceIt("removing taint cancels eviction [Disruptive]", func() { </ins> podName := "taint-eviction-4" pod := createPodForTaintsTest(true, 2*additionalWaitPerDeleteSeconds, podName, podName, ns) observedDeletions := make(chan string, 100)

Related discussion:
text: What happened: Ran a conformance test run (using Sonobuoy) on One of the taint based tests a NoExecute taint to a node which evicted all workloads including the Sonobuoy workload itself. If this had been a prod workload, numerous prod workloads could have been impacted. What you expected to happen: Test run as normal with reasonable results. Able to run conformance tests with minimal impact on a running cluster. How to reproduce it (as minimally and precisely as possible): on a v1.16.0 cluster. Anything else we need to know?: Environment: Kubernetes version (use ): /area conformance
/sig testing /sig architecture /sig scheduling
Summarizing the many conversations on the PR and in Slack regarding this: We wish we had identified the lack of a tag sooner and could have taken better action. Since the release is 2 days away and our own tooling currently prohibits us from marking tests as both and , we've decided to let the release proceed with this "bug". Risk: Someone running the conformance tests may unexpectedly have their workloads evicted Mitigation: Sonobuoy v0.16.0 will provide the capabilities to the user to run a "conformance-lite" (name TBD) run if they'd like to run the conformance tests against a cluster with prod workloads. This way end-users can still be reasonably sure of their cluster's continued well-being. This mode will manually skip the tests in question until they can be more appropriately marked as Sonobuoy will also provide, consistent with past behavior, the means to run the full conformance suite including these disruptive tests. Eventual solution: Sonobuoy will, most likely, need to continue offering a "non-disruptive-conformance" mode to aid in end user testing but the regexp will change and should be able to just skip tests K8s tooling needs to be tweaked to allow for tests to be marked as The tag should be to these tests.
Code change:
} }) <del> It("should not start app containers if init containers fail on a RestartAlways pod", func() { </del> <ins> /* Release: v1.12 Testname: init-container-fails-stops-app-restartalways-pod Description: Ensure that app container is not started when all InitContainers failed to start and Pod has restarted for few occurrences and pod has restart policy as RestartAlways. */ framework.ConformanceIt("should not start app containers if init containers fail on a RestartAlways pod", func() { </ins> By("creating the pod") name := "pod-init-" + string(uuid.NewUUID()) value := strconv.Itoa(time.Now().Nanosecond())

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Evaluating e2e tests based on available options which are covering important aspects with user scenarios and eligible to promote for conformance. What you expected to happen: These 4 e2e tests evaluate different and based on . [NodeConformance] should invoke init containers on a RestartNever pod [NodeConformance] should invoke init containers on a RestartAlways pod [NodeConformance] should not start app containers if init containers fail on a RestartAlways pod [NodeConformance] should not start app containers and fail the pod if init containers fail on a RestartNever pod Anything else we need to know?: comment, Are these tests good to promote for conformance or do we need to look on other aspects as well ? are observed api endpoint hits during tests execution. (API coverage improvement) - InitContainer [NodeConformance] should invoke init containers on a RestartNever pod InitContainer [NodeConformance] should invoke init containers on a RestartAlways pod InitContainer [NodeConformance] should not start app containers if init containers fail on a RestartAlways pod InitContainer [NodeConformance] should not start app containers and fail the pod if init containers fail on a RestartNever pod /area conformance cc
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
Go ahead and open a PR to ask this question. Yes == PR is merged, no == PR is closed (or amended to doc the reason these tests can't be promoted)
Code change:
totalConfTests, totalLegacyTests, missingComments int // If a test name contains any of these tags, it is ineligble for promotion to conformance <del> regexIneligibleTags = regexp.MustCompile(`[(Alpha|Disruptive|Feature:[^]]+|Flaky)]`) </del> <ins> regexIneligibleTags = regexp.MustCompile(`[(Alpha|Feature:[^]]+|Flaky)]`) </ins> ) const regexDescribe = "Describe|KubeDescribe|SIGDescribe"

Related discussion:
text: What would you like to be : Our tooling that makes the list of conformance tests needs to allow conformance tests to be marked as disruptive. Why is this needed: To test default, conformance behavior which may be disruptive (e.g. taint eviction) ref /sig testing /area conformance
Code change:
totalConfTests, totalLegacyTests, missingComments int // If a test name contains any of these tags, it is ineligble for promotion to conformance <del> regexIneligibleTags = regexp.MustCompile(`[(Alpha|Disruptive|Feature:[^]]+|Flaky)]`) </del> <ins> regexIneligibleTags = regexp.MustCompile(`[(Alpha|Feature:[^]]+|Flaky)]`) </ins> ) const regexDescribe = "Describe|KubeDescribe|SIGDescribe"

Related discussion:
text: What happened: Ran a conformance test run (using Sonobuoy) on One of the taint based tests a NoExecute taint to a node which evicted all workloads including the Sonobuoy workload itself. If this had been a prod workload, numerous prod workloads could have been impacted. What you expected to happen: Test run as normal with reasonable results. Able to run conformance tests with minimal impact on a running cluster. How to reproduce it (as minimally and precisely as possible): on a v1.16.0 cluster. Anything else we need to know?: Environment: Kubernetes version (use ): /area conformance
/sig testing /sig architecture /sig scheduling
Summarizing the many conversations on the PR and in Slack regarding this: We wish we had identified the lack of a tag sooner and could have taken better action. Since the release is 2 days away and our own tooling currently prohibits us from marking tests as both and , we've decided to let the release proceed with this "bug". Risk: Someone running the conformance tests may unexpectedly have their workloads evicted Mitigation: Sonobuoy v0.16.0 will provide the capabilities to the user to run a "conformance-lite" (name TBD) run if they'd like to run the conformance tests against a cluster with prod workloads. This way end-users can still be reasonably sure of their cluster's continued well-being. This mode will manually skip the tests in question until they can be more appropriately marked as Sonobuoy will also provide, consistent with past behavior, the means to run the full conformance suite including these disruptive tests. Eventual solution: Sonobuoy will, most likely, need to continue offering a "non-disruptive-conformance" mode to aid in end user testing but the regexp will change and should be able to just skip tests K8s tooling needs to be tweaked to allow for tests to be marked as The tag should be to these tests.
Code change:
} else { // Unable to get the priority class for reasons other than "not found". klog.Warningf("unable to get PriorityClass %v: %v. Retrying...", pc.Name, err) <del> return false, err </del> <ins> return false, nil </ins> } } }

Related discussion:
text: <!-- 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!--What happened: I've bootstrapped a cluster with kubeadm on a banana pi, it is up and running. Upon restarting, some process is slow that kube-apiserver does not boot up, exits with last lines: What you expected to happen: Expected the kube-apiserver to start up. How to reproduce it (as minimally and precisely as possible): On a banana pi (A20) bootstrap a cluster with kubeadm, add kube-router cni, and then restart kubelet. Anything else we need to know?: The version below contains a proposed fix, that is why the GitVersion is dirty. Environment: Kubernetes version Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-12-13T10:39:04Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/arm"} Server Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.2-beta.0.1+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2018-12-18T19:10:37Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"linux/arm"} Cloud provider or hardware configuration: Banana pi m1 plus OS (e.g. from /etc/os-release): PRETTYNAME="Debian GNU/Linux 9 (stretch)" NAME="Debian GNU/Linux" VERSIONID="9" VERSION="9 (stretch)" ID=debian HOMEURL="" SUPPORTURL="" BUGREPORTURL="" Kernel (e.g. ): Linux k8s-master 4.9.0-8-armmp SMP Debian 4.9.130-2 (2018-10-27) armv7l GNU/Linux Install tools: kubeadm Others: Seems that in AddSystemPriorityClasses() adds a function which uses wait.Poll. On line 95 it logs 'Retrying...', howewer the return statement tells wait.Poll() to stop polling.
Code change:
} else { // Unable to get the priority class for reasons other than "not found". klog.Warningf("unable to get PriorityClass %v: %v. Retrying...", pc.Name, err) <del> return false, err </del> <ins> return false, nil </ins> } } }

Related discussion:
text: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig api-machinery
/cc
If we solve it, we want a piece of pie :)