jiebi/CodeConvo huggingface dataset:
Change:
numNodes, err := e2enode.TotalRegistered(f.ClientSet) framework.ExpectNoError(err) replicas := int32(numNodes) <del> common.NewRCByName(c, ns, name, replicas, nil) </del> <ins> common.NewRCByName(c, ns, name, replicas, nil, nil) </ins> err = e2epod.VerifyPods(c, ns, name, true, replicas) framework.ExpectNoError(err, "Each pod should start running and responding")

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-serial Which test(s) are failing: [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to add nodes [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to delete nodes Since when has it been failing: These tests have been failing since 6/28 Failures coincide with the following changes: Testgrid link: Reason for failure: The failure messages look as follows: [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to add nodes [sig-cluster-lifecycle] Nodes [Disruptive] Resize [Slow] should be able to delete nodes /cc /milestone v1.16 /priority critical-urgent /kind failing-test /cc
/sig cluster-lifecycle
For more context, the code for the failing tests is here The error for both comes through  - some Pod is not responding. It is failing to find pods prefixed with "my-hostname-add-node". Within the logs we can see this: So the Pods are stuck in a Pending state. The Pods are supposed to be created by a ReplicationController in , which itself uses this method from the e2e framework . However, after being in a Pending state (after the "failed to wait for pods responding: timed out waiting for the condition" error is registered), they do seem to reach a Ready state
/assign for triage.
I think agnhost needs to be passed , but did not do so in /assign sig-testing
GitHub didn't allow me to assign the following users: sig-testing. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : I think agnhost needs to be passed , but did not do so in 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
Reopen to monitor job /reopen
Reopened this issue.

<detailsIn response to : Reopen to monitor job /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
Thank you for working on the PR to solve this. indeed solved the issue reported here. /close
Closing this issue. <detailsIn response to : Thank you for working on the PR to solve this. /close 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
Change:
Items: []corev1.Pod{*testPodWithOneContainers()}, }, actions: []testclient.Action{ <del> getLogsAction("test", nil), </del> <ins> getLogsAction("test", &corev1.PodLogOptions{Container: "c1"}), </ins> }, expectedSources: []corev1.ObjectReference{{ Kind:       testPodWithOneContainers().Kind,

Discussion:
/kind bug The logs of pods with label will be output expected without errors. create the following resources: kubectl logs -l Kubernetes version (use ): latest master.
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 cli
I am able to pull logs from multiple containers in my test setup, this doesn't seem to be an issue with Could you check if all the containers in the specified pod are healthy?
yes, all of these pods' containers are healthy. I the section.
This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close
Closing this issue. <detailsIn response to : This is working as expected, was not able to find the default container which in both deployments you explicitly said is but only the first deployment has container, the second deployment has . /close 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
Change:
// Output: // clusters: //   cow-cluster: <del> //     LocationOfOrigin: "" </del> //     certificate-authority-data: DATA+OMITTED //     server: http://cow.org:8080 // contexts: //   federal-context: <del> //     LocationOfOrigin: "" </del> //     cluster: cow-cluster //     user: red-user // current-context: federal-context // preferences: {} // users: //   red-user: <del> //     LocationOfOrigin: "" </del> //     client-certificate-data: DATA+OMITTED //     client-key-data: DATA+OMITTED //     token: REDACTED

Discussion:
yaml.Marshal a kubeconfig, as done in the example tests here LocationOfOrigin is not seen in output, as comment says "never serialized." Click "run example" doesn't suffer from this as it does some conversion <details</details<details</details<details</details<details</details<details</details<details</details
/assign
/sig api-machinery
/assign /triage accepted
is what's known as internal type. It is not intended to be serialized by code. The serialization version is in and does not have this field. I could get behind removing all json tags from the internal version, but I wouldn't refine tags that shouldn't be used.
Change:
// policy of the containers in which the Pod is running. Parallelism is the Job's parallelism, and completions is the // Job's required number of completions. func NewTestJob(behavior, name string, rPol v1.RestartPolicy, parallelism, completions int32, activeDeadlineSeconds *int64, backoffLimit int32) *batchv1.Job { <ins> anyNode := "" return NewTestJobOnNode(behavior, name, rPol, parallelism, completions, activeDeadlineSeconds, backoffLimit, anyNode) } // NewTestJobOnNode is similar to NewTestJob but supports specifying a Node on which the Job's Pods will run. // Empty nodeName means no node selection constraints. func NewTestJobOnNode(behavior, name string, rPol v1.RestartPolicy, parallelism, completions int32, activeDeadlineSeconds *int64, backoffLimit int32, nodeName string) *batchv1.Job { </ins> manualSelector := false job := &batchv1.Job{ ObjectMeta: metav1.ObjectMeta{

Discussion:
Which jobs are flaking: pull-kubernetes-e2e-kind Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: /sig apps
Failure at
Hi I looked into the failures and think it was because the test required the job succeeds 3 times with pseudorandom 50% failure chance within 15 minutes, while there is an exponential back-off delay (10s, 20s, 40s …) capped at 6 minutes before recreating failed pods. As 7 consecutive failures (1/128 chance) could exceed the timeout, the test failed intermittently because of "timed out waiting for the condition". For example, in the failure of , the job pods succeeded and failed in the following orders: After the last failure at , the delay has increased to 640s so no pod was created any more before the test failed at . I think it can be fixed by using a deterministic approach to make the job pods succeed and fail alternately, and its executing time can be reduced to tens of seconds stably. Assigning myself. /assign
Change:
} } <del> // For a given node checks its conditions and tries to update it. Returns grace period to which given node // is entitled, state of current and last observed Ready Condition, and an error if it occurred. </del> <ins> // tryUpdateNodeStatus checks a given node's conditions and tries to update it. Returns grace period to // which given node is entitled, state of current and last observed Ready Condition, and an error if it occurred. </ins> func (nc *NodeController) tryUpdateNodeStatus(node *v1.Node) (time.Duration, v1.NodeCondition, *v1.NodeCondition, error) { var err error var gracePeriod time.Duration

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: If node is unreachable, NodeController only set , , to unknown; it's better to also set NetworkUnavailable & InodePressure to unknown.
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig node
Isn't a known condition if node is unreachable?
is the status of container, e.g. CNI is not ready. If node is unreachable, it should be Unknown.
Thanks for explanation!
will not set NetworkUnavailable & InodePressure to unknown, refer to .
Change:
} func TestEnsureLoadBalancerDeletedDeletesExternalLb(t *testing.T) { <del> t.Parallel() </del> vals := DefaultTestClusterValues() gce, err := fakeGCECloud(vals) require.NoError(t, err)

Discussion:
Since merged on Friday night, my PR () has failed several retests of pull-kubernetes-bazel-test. My PR is unrelated to the load balancer so I suspect that introduced a flake. I see several runs of that test against master that aren't failing, so clearly the test works sometimes (and the original PR passed it several times to before it merged). Perhaps the test harness sometimes runs problem tests in parallel and other times it doesn't. Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: My PR had one good run of pull-kubernetes-bazel-test before merged, but has failed several times since with no code changes to my PR. What you expected to happen: The tests should consistently pass unless related problem code is introduced.
/cc /cc /sig gcp /kind flake
My PR started failing recently too. See https://k8s-
Hey, thanks for identifying the issue. contains tests for - but the race condition was caused when tests with modified a singleton variable in a mock. The short-term fix is removing the calls, but the long-term fix is to not use a singleton. Fix is .
Change:
record_command run_kubectl_apply_deployments_tests fi <ins> ################ # Kubectl diff # ################ record_command run_kubectl_diff_tests </ins> ############### # Kubectl get # ###############

Discussion:
/kind bug /sig cli /area kubectl Hello. This is my first interaction with the Kubernetes community, so please forgive me if i have left out any crucial details, or if, perhaps, this is PEBKAC after all! I am keen to have a working feature, as described in and I am running K8s v1.9.3 and realise that this feature is in alpha, but i thought i would ask anyway. We're not on v1.9.4 yet, but the changelog doesn't mention the feature. What you expected to happen: I have some services deployed to Kubernetes with YAML files, that has been working reliably. We always use to deploy things. When a service is already deployed, and i make a minor change in the config file, for example the service port, i expect to see that in the diff. Instead, gives no output and exits with a . How to reproduce it (as minimally and precisely as possible): Consider the file : I make sure that it is correctly running on the cluster: Great, looking good. Now, i change the value to use Docker image tag and save. Now, i run: The stderr/stdout output is empty, and the exit code is . Anything else we need to know?: Environment: Kubernetes version: Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-02-09T21:50:44Z", GoVersion:"go1.9.4", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.3+coreos.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-02-10T01:42:55Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}
I have this same issue - if I change, say, to in my , running returns empty. If I try tweaking the version I'm diffing (which I don't understand) - e.g. - then I see a bunch of differences, but not actually the change I was expecting in the number of replicas.
I'll take this. Sorry for the inconvenience.
Change:
}}) } <ins> // MaintainObservations keeps the observers from // metrics.PriorityLevelConcurrencyObserverPairGenerator from falling // too far behind func (cfgCtlr *configController) MaintainObservations(stopCh <-chan struct{}) { wait.Until(cfgCtlr.updateObservations, 10*time.Second, stopCh) } func (cfgCtlr *configController) updateObservations() { cfgCtlr.lock.Lock() defer cfgCtlr.lock.Unlock() for _, plc := range cfgCtlr.priorityLevelStates { if plc.queues != nil { plc.queues.UpdateObservations() } } } </ins> func (cfgCtlr *configController) Run(stopCh <-chan struct{}) error { defer cfgCtlr.configQueue.ShutDown() klog.Info("Starting API Priority and Fairness config controller")

Discussion:
<!-- 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: Not observed yet, but deduced from analyzing the code. If a k/apiserver/pkg/util/flowcontrol/fairqueuing.QueueSet, whose metrics.TimedObserverPair is a pair of k/apiserver/pkg/util/flowcontrol/metrics.sampleAndWaterMarkHistograms, gets zero activity for a long while and then gets some activity, then the loop at will go through a lot of iterations, and do so with a lock held. What you expected to happen: No big hiccups in any scenario. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): branch 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:
/assign

<!-- 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: In reviewing I noticed an incorrect fake implementation of Interface. I looked at the comment on the Handle method, and noticed that it does not say when/how the is called. What you expected to happen: I expected the parameter to be as well documented as the others. How to reproduce it (as minimally and precisely as possible): Look at and see how it does not say when/whether/with-what-parameter-values is called. Anything else we need to know?: Environment: Kubernetes version (use ): current 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:
Any chance we could write a test for the interface which verifies correct plumbing?
/cc
: that should be do-able
Change:
predicate := func(actual []string) bool { return len(actual) == 0 } <del> t.checkDNSRecord(federationDNS, predicate, wait.ForeverTestTimeout) </del> <ins> t.checkDNSRecordFrom(federationDNS, predicate, "cluster-dns", wait.ForeverTestTimeout) </ins> } } else { for label := range federations {

Discussion:
/kind failing-test /priority critical-urgent /sig network /milestone v1.12 /cc
ping
Also failures on
TLS errors connection refused 503 service unavailable especially around metrics and healthz in ways that make me suspect things didn't start correctly. Or perhaps API mismatch? /cc 've looked at some similar failures in the past. Any chance you might give a look over this and ?
in both and here looks like api mismatch?
Test output shows no DNS server can be reached, but logs say coredns pods are running (https://k8s-): cc
The CoreDNS configmap is incorrectly configured and hence the test fails. I'm working on the fix.
/assign
, , Does it make sense to keep that e2e test ?, knowing that this test is specific for "Federation" and that federation has now merged into "multicluster" and removed all e2e tests about "Federation + Serial" (formerly "ci-federation-e2e-gce-serial") : can you say if that use case is still supported in kubernetes v1.12 ?
I can say that Federation v1 has not been exercised since v1.10. I think a good question for the Federation v2 folks is not only whether they still need the tests, but also whether they need the configmap support specific to what Federation v1 used -- I'll defer to
If ya'll decide the use case is no longer valid, please open an issue / remove the test once 1.13 release opens.
tests are failing
/reopen /cc
Reopening this issue. <detailsIn response to : /reopen /cc 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
More failures:
Looks like this is failing since Kube-dns is now enabled.
Since we'd previously discussed this not being a relevant test case, and it seems less appropriate even if it's this coupled to the dns implementation and we've got the kube-dns to coredns transition happening in the next release most likely....Can we just disable/remove the test?
Opened to disable this test.
Thank you!
Change:
const ( // SampleDevicePluginDSYAML is the path of the daemonset template of the sample device plugin. // TODO: Parametrize it by making it a feature in TestFramework. <del> SampleDevicePluginDSYAML                    = "test/e2e/testing-manifests/sample-device-plugin.yaml" </del> <ins> SampleDevicePluginDSYAML                    = "test/e2e/testing-manifests/sample-device-plugin/sample-device-plugin.yaml" </ins> SampleDevicePluginControlRegistrationDSYAML = "test/e2e/testing-manifests/sample-device-plugin/sample-device-plugin-control-registration.yaml" // SampleDevicePluginName is the name of the device plugin pod

Discussion:
Serial e2e node jobs, e.g. Since 03-01 No response Seems related to No response /sig node
Failing run -
I think there is a typo there - should fix it
cc
/triage accepted
/cc
Change:
Args: []string{ "--logtostderr", fmt.Sprintf("--system-log-monitors=%s", configFile), <del> fmt.Sprintf(" --apiserver-override=%s?inClusterConfig=true", framework.TestContext.Host), </del> <ins> // `ServiceAccount` admission controller is disabled in node e2e tests, so we could not use // inClusterConfig here. fmt.Sprintf("--apiserver-override=%s?inClusterConfig=false&auth=%s", framework.TestContext.Host, kubeConfigFile), </ins> }, Env: []v1.EnvVar{ {

Discussion:
Which jobs are failing: Which test(s) are failing: Since when has it been failing: Last successful run (23 Oct 2020, 10:07 PDT): First unsuccessful run (23 Oct 2020, 12:08 PDT): Testgrid link: Reason for failure: Anything else we need to know: presubmit job in repository also started to fail in the same fashion. Attempted to debug it myself, found out the following stuff: last successful run was accessing the apiserver via HTTP: all unsuccessful runs attempted to access the apiserver via HTTPS but to no avail: perused the history of to find out that the PR is almost certainly the reason of the failures (or rather uncovered some problem with the NPD or its tests): first, it coincides with the start of the failures of , second, we changed the default hostname of the apiserver in node tests in that PR. Judging by the code and the changes in the aforementioned PR I think that a quick mitigation would be to add a flag to the of these jobs. /assign /sig node /cc
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
Opened for a mitigation that would make those jobs stop failing.
This won't work, unfortunately. Copying response:
I have filed to address this issue, but it seems I could not run the test in advance to verify my patch, did you know how to manually trigger the presubmit job?
Unfortunately I don't :/. My PR was also a wild guess. could you take a look at the proposed fix? Thanks once again for your help - really appreciated :).
the submission of hasn't fixed the problems, unfortunately :/. Sample failing run: We still have some peculiar problem related to health checking: and now NPD panics, too:
Thanks for your report, I believe the reason is admission controller has been disabled in node e2e tests: We need to figure out a new approach now. /reopen
Reopened this issue.

<detailsIn response to : Thanks for your report, I believe the reason is admission controller has been disabled in node e2e tests: We need to figure out a new approach now. 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
filed . I hope we could completely address this issue this time.
/milestone v1.20
Change:
ADD https://github.com/coredns/coredns/releases/download/v1.5.0/coredns_1.5.0_windows_amd64.tgz /coredns.tgz ADD https://iperf.fr/download/windows/iperf-2.0.9-win64.zip /iperf.zip <ins> ADD http://download.savannah.nongnu.org/releases/coreutils/windows-64bit-unsupported/coreutils-8.31-28-windows-64bit.zip /coreutils.zip </ins> # we're also creating an empty /uploads folder, which we're copying over to Windows  because # we can't RUN commands on a Windows image. RUN tar -xzvf /coredns.tgz && unzip iperf.zip && mv iperf-2.0.9-win64 iperf && <ins> unzip coreutils.zip && mv coreutils-8.31-28-windows-64bit wincoreutils && </ins> mkdir /uploads FROM --platform=linux/amd64 $REGISTRY/windows-servercore-cache:1.0-linux-amd64-$OS_VERSION as servercore-helper

Discussion:
We'd like to add to the windows nodes Discussed in , some storage e2e tests need the call to flush data to disk, this utility is not available in windows nodes or agnhost /sig storage /sig testing
/sig testing
/sig storage /kind flake
/sig windows
Does sync only need to be in Agnhost or also on the Windows node? I don't think there is any issue with adding to the agnhost for this tests. Has it been tested that it works? /cc in case you have thoughts
In the README of sync it says: Initially I thought it could be to agnhost however told me that Windows containers cannot run in privileged mode as of today. cc
Since we run the Windows Test containers as they should have full access to modify the host files if the host path is mapped in.
I downloaded the zip file and I checked that it has an EULA, do you know which sig would help with the license?
Hm, if the sysinternal is problematic, what about the GNU one? It seems to come from coreutils, which can easily be downloaded and extracted from. Hopefully, they are 64-bit binaries. Anyways, I think adding is a good idea, there are a few other non-conformance tests that are calling sync.
I believe that would be sig-contributor-experience. I thought we were using other sys-internal tools as well but it is a good idea to double check.
/triage accepted /assign
/remove-sig testing we don't own the nodes (?)
I've sent , which would add using that PR. Let us know if that satisfies your requirements, we could merge afterwards.
Thanks I guess we can merge the PR and I can run the storage e2e tests that need .