jiebi/CodeConvo huggingface dataset:
Code change:
framework.SkipUnlessProviderIs("gke") nsFlag := fmt.Sprintf("--namespace=%v", ns) podJson := readTestFileOrDie(kubectlInPodFilename) <ins> // Replace the host path to kubectl in json podString := strings.Replace(string(podJson), "$KUBECTL_PATH", framework.TestContext.KubectlPath, 1) </ins> By("validating api verions") <del> framework.RunKubectlOrDieInput(string(podJson), "create", "-f", "-", nsFlag) </del> <ins> framework.RunKubectlOrDieInput(podString, "create", "-f", "-", nsFlag) </ins> err := wait.PollImmediate(time.Second, time.Minute, func() (bool, error) { output := framework.RunKubectlOrDie("get", "pods/kubectl-in-pod", nsFlag) if strings.Contains(output, "Running") {

Related discussion:
text: https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes
Code change:
framework.SkipUnlessProviderIs("gke") nsFlag := fmt.Sprintf("--namespace=%v", ns) podJson := readTestFileOrDie(kubectlInPodFilename) <ins> // Replace the host path to kubectl in json podString := strings.Replace(string(podJson), "$KUBECTL_PATH", framework.TestContext.KubectlPath, 1) </ins> By("validating api verions") <del> framework.RunKubectlOrDieInput(string(podJson), "create", "-f", "-", nsFlag) </del> <ins> framework.RunKubectlOrDieInput(podString, "create", "-f", "-", nsFlag) </ins> err := wait.PollImmediate(time.Second, time.Minute, func() (bool, error) { output := framework.RunKubectlOrDie("get", "pods/kubectl-in-pod", nsFlag) if strings.Contains(output, "Running") {

Related discussion:
text: e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
Are you the correct assignee for this? If so, can you please give an update. If not, can you please reassign it to the correct person. CC
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
Yes, I guess so. I'm looking into it.
Code change:
framework.SkipUnlessProviderIs("gke") nsFlag := fmt.Sprintf("--namespace=%v", ns) podJson := readTestFileOrDie(kubectlInPodFilename) <ins> // Replace the host path to kubectl in json podString := strings.Replace(string(podJson), "$KUBECTL_PATH", framework.TestContext.KubectlPath, 1) </ins> By("validating api verions") <del> framework.RunKubectlOrDieInput(string(podJson), "create", "-f", "-", nsFlag) </del> <ins> framework.RunKubectlOrDieInput(podString, "create", "-f", "-", nsFlag) </ins> err := wait.PollImmediate(time.Second, time.Minute, func() (bool, error) { output := framework.RunKubectlOrDie("get", "pods/kubectl-in-pod", nsFlag) if strings.Contains(output, "Running") {

Related discussion:
text: https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
We need to get this fixed soon and picked up in release-1.5 since it is consistently red in
ack i have a PR currently running
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
If you found the root cause, we will close my pending PR that printing out some debug info. What is the PR # of the commit you mentioned above?
Code change:
framework.SkipUnlessProviderIs("gke") nsFlag := fmt.Sprintf("--namespace=%v", ns) podJson := readTestFileOrDie(kubectlInPodFilename) <ins> // Replace the host path to kubectl in json podString := strings.Replace(string(podJson), "$KUBECTL_PATH", framework.TestContext.KubectlPath, 1) </ins> By("validating api verions") <del> framework.RunKubectlOrDieInput(string(podJson), "create", "-f", "-", nsFlag) </del> <ins> framework.RunKubectlOrDieInput(podString, "create", "-f", "-", nsFlag) </ins> err := wait.PollImmediate(time.Second, time.Minute, func() (bool, error) { output := framework.RunKubectlOrDie("get", "pods/kubectl-in-pod", nsFlag) if strings.Contains(output, "Running") {

Related discussion:
text: https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
: here it is
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
We timeout waiting for pod sometimes. Is it reasonable to use a longer timeout? Use for in that test.
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
: sure thing, do you want to do that in a fresh PR?
I updated my pending PR .
https://k8s- Failed: [] Kubectl client [] Kubectl should be able to talk to api server kubectl running in a pod could talk to api server [Conformance] {Kubernetes e2e suite}
Code change:
podLabels := map[string]string{"name": "nginx"} replicas := 1 Logf("Creating simple deployment %s", deploymentName) <del> _, err := c.Deployments(ns).Create(newDeployment(deploymentName, replicas, podLabels, "nginx", "nginx")) </del> <ins> _, err := c.Deployments(ns).Create(newDeployment(deploymentName, replicas, podLabels, "nginx", "nginx", extensions.RollingUpdateDeploymentStrategyType)) </ins> Expect(err).NotTo(HaveOccurred()) defer func() { deployment, err := c.Deployments(ns).Get(deploymentName)

Related discussion:
text: There's some practical limit on the number of concurrent access tokens that can be used in a Kubernetes cluster before it begins to spend all of its time in the authn stack verifying them. Absent fixes to it was < 500; with the fixes linked there it's still not infinitely scalable-- I still hit (what I believe to be) with ~ 5k unique tokens @ ~700QPS. This request is to this dimension an official name & definition, and list it with others, e.g. here: it it have a useful value (I think it should be 10k) /kind bug /sig scalability
/cc
oh and 4. add tests which verify it is as high as believed.
cc since projected tokens will increase the number of unique tokens
/sig auth
LRUs are not good at scaling and sharding has some major pitfalls as pointed out. I would suggest that we try to drop the LRU cache for successful authentication results in the token cache. The main benefit of using an LRU here is bound cache size. Entries in the token cache have a fast expiration independent of the LRU policy. The records probably take up O(2kb) (guesstimate) of memory. Given that these are successful attempts with presumably valid tokens, I don't think we are getting any benefit from the LRU. If we don't have a constraint on fixed cache size, we can back the token cache with a sync.Map and run a single background goroutine to periodically walk the map and remove expired entries. This would fix the problematic locking and eviction due to nonuniform distribution of tokens over shards. The failure cache is less important and we don't cache failures by default. If we consider this the "slowpath", we can probably leave it as. If that's not good enough, we have a couple options (with various tradeoffs) to improve it.
If off by default is not enough, more reasoning why the failed cache is not super useful: it might help with an accidental DoS but it doesn't prevent anything actively malicious DoS. I think we can focus our improvements on the success cache.
/assign He is already working on adding an explicit test for it.
has taken it over and is actively working on this. Unfortunately, I cannot assign this issue to him as he's not a k8s member yet
It's not closed - all testes must be submitted and appropriate documentation must be
Thanks everyone!!
Code change:
} return parameters, nil default: <ins> sort.Slice(objs, func(i, j int) bool { obj1, obj2 := objs[i].(*resourcev1alpha2.ResourceClassParameters), objs[j].(*resourcev1alpha2.ResourceClassParameters) if obj1 == nil || obj2 == nil { return false } return obj1.Name < obj2.Name }) </ins> return nil, statusError(logger, fmt.Errorf("multiple generated class parameters for %s.%s %s found: %s", class.ParametersRef.Kind, class.ParametersRef.APIGroup, klog.KRef(class.Namespace, class.ParametersRef.Name), klog.KObjSlice(objs))) } }

Related discussion:
text: master-blocking: ci-kubernetes-unit It starts flaking today 30-05-2024 The test fail is This failure may be caused by the error message's order sensitivity. The error message's order of Resource Classes versus is different. N/A /sig node /sig scheduling
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
/remove-sig testing /sig scheduling (sig testing doesn't own all of the unit tests, just test frameworks, tooling, CI infra, etc) This appears to be a flake in scheduler unit tests which would be sig scheduling ( )
.. and it appears to be DRA specific subset of scheduling so /sig node as well
FYI - looks like this is happening every 3-6 hours give or take. Yesterday it was every six hours and today it seems to be every 3-4 hours. Looking into it a bit more, it looks like it may just be an issue with a connection via the test while it's trying to hit the server. I don't think the test itself is failing, I think the connection to the server is failing. ! CC
Hey All - hope you're well. Michael here from the Release Signal team. Just wanted to touch base and make sure we're good to go for the cut on the 4th. CC /sig-node
Code change:
ExitCode: 5, }, }, <del> map[string]error{"with-reason": testErrorReason, "succeed": testErrorReason}, []api.ContainerStatus{}, map[string]api.ContainerState{ </del> <ins> reasons:     map[string]error{"with-reason": testErrorReason, "succeed": testErrorReason}, oldStatuses: []api.ContainerStatus{}, expectedState: map[string]api.ContainerState{ </ins> "without-reason": {Terminated: &api.ContainerStateTerminated{ ExitCode:    1, ContainerID: emptyContainerID,

Related discussion:
text: is this a Node bug? cc as next oncall to follow up on this.
This is a node bug due to init containers
I may need help debugging - I see:
So I think the problem is in the error case - we're not properly recording that the start failed, and the next time we come in we somehow think the first container succeeded. I'll add some debugging to see if we can't recreate it.
Let's discuss on instead.
Code change:
ExitCode: 5, }, }, <del> map[string]error{"with-reason": testErrorReason, "succeed": testErrorReason}, []api.ContainerStatus{}, map[string]api.ContainerState{ </del> <ins> reasons:     map[string]error{"with-reason": testErrorReason, "succeed": testErrorReason}, oldStatuses: []api.ContainerStatus{}, expectedState: map[string]api.ContainerState{ </ins> "without-reason": {Terminated: &api.ContainerStateTerminated{ ExitCode:    1, ContainerID: emptyContainerID,

Related discussion:
text: Kubelet issues a docker inspect call after creating a container, but for very short lived containers there is a window in which they could exit before being inspected in the docker manager. If the container PID is 0, we should check the ExitCode and other relevant fields and handle them appropriately. [1] This is the suspected cause of several flakes: /cc
looking at the logs 2 weird things: race described second container ran, which suggests inconsistent reporting of initialized status of init1 and choosing init2 as the next container ( vs ). I think 1 got it right and 2 got it wrong. From logs: I'd expect the second one to not have run in this case? Node logs:
Init containers have an implicit assumption that container statuses include results of previous SyncPod invocations. If that's not the case we may need to fix that (or at least mitigate it). On May 18, 2016, at 8:28 PM, Prashanth B wrote: looking at the logs 2 weird things: race described second container ran, which suggests inconsistent reporting of initialized status of init1 and choosing init2 as the next container ( vs ). I think 1 got it right and 2 got it wrong. From logs: May 18 15:58:33.380: INFO: pod-init--1d4b-11e6-80a4- started at 2016-05-18T15:58:04-07:00 (2+1 container statuses recorded) May 18 15:58:33.380: INFO: Init container init1 ready: false, restart count 0 May 18 15:58:33.380: INFO: Init container init2 ready: true, restart count 0 I'd expect the second one to not have run in this case? Node logs: — You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub
This should be true. Is there any evidence that suggests the opposite? only shows conflicting view of whether init1 has run.
If the container exits already and it's not an infra container, kubelet should not error out. Although even if it does, I failed to see how this could affect the readiness of the init container without checking the code further.
Code change:
ExitCode: 5, }, }, <del> map[string]error{"with-reason": testErrorReason, "succeed": testErrorReason}, []api.ContainerStatus{}, map[string]api.ContainerState{ </del> <ins> reasons:     map[string]error{"with-reason": testErrorReason, "succeed": testErrorReason}, oldStatuses: []api.ContainerStatus{}, expectedState: map[string]api.ContainerState{ </ins> "without-reason": {Terminated: &api.ContainerStateTerminated{ ExitCode:    1, ContainerID: emptyContainerID,

Related discussion:
text: Each syncPod invocation, we inspect the list of init container in order looking for lastTerminationState. There could be a bug in that logic, or if we didn't get the full status, we might make a bad decision. When determining which container to run next, we always look for the last init container in the chain that has success, then run the next container (unless the pod is RestartNever). , Yu-Ju Hong wrote:
Saw this flake again. How do we verify that container status is not lost between syn pods?
... between calls to syncPods
The second sync clearly saw the init1 container, and decided to launch init2. See "InitContainersToKeep" in the message below.
containers to keep can include failed containers. , Yu-Ju Hong wrote:
Discussed on slack. In summary, the problem has to do with how we convert the kubecontainer.PodStatus to the api.PodStatus. If a container is terminated, the function makes the decisions: the pod restart policy is "Always", and there is a "failure reason" recorded for the given container, this means the pod worker tried to (re)start the container but failed. Set the state to "Waiting" and populate the reason. , the container state is simply "terminated". Init containers don't obey the restart policy like regular containers, and the logic will need to be amended to work with them. is working on a PR. In addition to that, kubelet should not error out if a user container exited before it could apply the oom score (which is best effort in this case). fixes that.
Ahh, thanks for digging into the issue. This is the exact the concern I had when I reviewed the initial implementation of init container, which blocks pr for a while. I even asked to help me verify this case, unfortunately we didn't reproduce the issue back then. :-(
I wish I'd seen the flakes in the runs prior to merge.
We didn't notice this until we started running the tests against docker v1.11.1, which is much faster and hit the race condition differently.
I suppose that's a good thing...
It is hard to reproduce this.
Code change:
ExitCode: 5, }, }, <del> map[string]error{"with-reason": testErrorReason, "succeed": testErrorReason}, []api.ContainerStatus{}, map[string]api.ContainerState{ </del> <ins> reasons:     map[string]error{"with-reason": testErrorReason, "succeed": testErrorReason}, oldStatuses: []api.ContainerStatus{}, expectedState: map[string]api.ContainerState{ </ins> "without-reason": {Terminated: &api.ContainerStateTerminated{ ExitCode:    1, ContainerID: emptyContainerID,

Related discussion:
text: The extra check of last terminated container in your initial code makes me nervous, but we couldn't reproduce it due to that small race windows until we have a faster docker running on the node. :-)
I got "Pods should invoke init containers on a RestartAlways pod" flake (referenced from ): Logs:
All the fixes went in. Please reopen this issue if you see any more flakes.
Code change:
// be sure to unset environment variable https_proxy (if exported) before testing, otherwise the testing will fail unexpectedly. func TestRoundTripSocks5AndNewConnection(t *testing.T) { <del> t.Skip("Flake https://issues.k8s.io/107708") </del> localhostPool := localhostCertPool(t) for _, redirect := range []bool{false, true} {

Related discussion:
text: TestRoundTripSocks5AndNewConnection Disabled by No response No response No response /sig
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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
there is a race shutting down the socks5 server