jiebi/CodeConvo huggingface dataset:
Code change:
What happened: I download fluentd-elasticsearch in addons. The following error occurs then I use "kubectl apply -f es- " Then, i find the elasticsearch-logging pod restart lots of time, and keep status with CrashLoopBackOff. [root ~]# kubectl logs -f elasticsearch-logging-0 -n kube-system export NODENAME=elasticsearch-logging-0 NODENAME=elasticsearch-logging-0 export NODEMASTER=true NODEMASTER=true export NODEDATA=true NODEDATA=true export HTTPPORT=9200 HTTPPORT=9200 export TRANSPORTPORT=9300 TRANSPORTPORT=9300 export MINIMUMMASTERNODES=2 MINIMUMMASTERNODES=2 chown -R elasticsearch:elasticsearch /data ./bin/elasticsearchloggingdiscovery I0902 14:25:06. 9 ] Kubernetes Elasticsearch logging discovery I0902 14:25:06. 9 ] Found [] I0902 14:25:16. 9 ] Found [] I0902 14:25:26. 9 ] Found [] I0902 14:25:36. 9 ] Found [] I0902 14:25:46. 9 ] Found [] I0902 14:25:56. 9 ] Found []
unclear whether the addon is up to date and supported at this point. /sig instrumentation
cc
/assign I will take a look this week.
I have the same problem k8s version:v1.18.8
same
I've pushed a change to the stateful set that should unblock people as there was a 1.18 compatibility problem. however, please make sure you are also creating the service via , the discovery program finds the other elasticsearch nodes via service registration.
please feel free to re-open this issue if the latest version doesn't work for you.
Why was this PR to v1.20?
probably because that is the next release. most people who use this addon do so from master. Do you need this packaged in some other way?

Related discussion:
text: k8s-app: elasticsearch-logging addonmanager.kubernetes.io/mode: Reconcile subjects: <del> - kind: ServiceAccount name: elasticsearch-logging namespace: kube-system apiGroup: "" </del> <ins> - kind: ServiceAccount name: elasticsearch-logging namespace: kube-system apiGroup: "" </ins> roleRef: kind: ClusterRole name: elasticsearch-logging
Code change:
Is this a valid test? My understanding is we cannot rely on events for programming against. Which jobs are flaking: ci-cri-containerd-node-e2e-features ci-kubernetes-node-kubelet-features among others, mainly 'node-e2e-features' based tests. Which test(s) are flaking: Testgrid link: Reason for failure: expected total number of events was 4, actual events counted was 7 Anything else we need to know: It doesn't fail in a specific environment, should this test be running at all outside of this job? The comments inside the test aren't very helpful for understanding why we're checking what we're checking.
I heard this is blocking you. /sig node /cc
I see flakes going back at least a month In addition to an earlier issue clarifying the error message This might be a spurious match,
NodeProblemDetector is broken on nearly every run:
Maybe they should be marked [serial] or [disruptive]?
We can mark it and move it to the flake job, but I fear it will work fine over there.
Edit in upstream issue says "needs to be marked serial" I'll make a PR

Related discussion:
text: "github.com/onsi/gomega" ) <del> var _ = framework.KubeDescribe("NodeProblemDetector [NodeFeature:NodeProblemDetector]", func() { </del> <ins> var _ = framework.KubeDescribe("NodeProblemDetector [NodeFeature:NodeProblemDetector] [Serial]", func() { </ins> const ( pollInterval   = 1 * time.Second pollConsistent = 5 * time.Second
Code change:
Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: TestDevicePluginReRegistrationProbeMode Testgrid link: Reason for failure: Anything else we need to know: Reproduce with /sig node
/assign
See
not sure this is actually fixed, I see a failure from today

Related discussion:
text: "//staging/src/k8s.io/apimachinery/pkg/api/resource:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/errors:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", </ins> "//staging/src/k8s.io/apiserver/pkg/util/feature:go_default_library", "//staging/src/k8s.io/kubelet/pkg/apis/deviceplugin/v1beta1:go_default_library", "//staging/src/k8s.io/kubelet/pkg/apis/pluginregistration/v1:go_default_library",
Code change:
Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: TestDevicePluginReRegistrationProbeMode Testgrid link: Reason for failure: Anything else we need to know: Reproduce with /sig node
/assign
See
not sure this is actually fixed, I see a failure from today

Related discussion:
text: "google.golang.org/grpc" <ins> "k8s.io/apimachinery/pkg/util/wait" </ins> "k8s.io/klog/v2" pluginapi "k8s.io/kubelet/pkg/apis/deviceplugin/v1beta1" watcherapi "k8s.io/kubelet/pkg/apis/pluginregistration/v1"
Code change:
Which jobs are flaking: pull-kubernetes-bazel-test Which test(s) are flaking: TestDevicePluginReRegistrationProbeMode Testgrid link: Reason for failure: Anything else we need to know: Reproduce with /sig node
/assign
See
not sure this is actually fixed, I see a failure from today

Related discussion:
text: defer m.wg.Done() m.server.Serve(sock) }() <del> _, conn, err := dial(m.socket) if err != nil { return err </del> <ins> var lastDialErr error wait.PollImmediate(1*time.Second, 10*time.Second, func() (bool, error) { var conn *grpc.ClientConn _, conn, lastDialErr = dial(m.socket) if lastDialErr != nil { return false, nil } conn.Close() return true, nil }) if lastDialErr != nil { return lastDialErr </ins> } <del> conn.Close() </del> klog.Infof("Starting to serve on %v", m.socket) return nil
Code change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig autoscaling Looks like it just started happening today (@ 2020-09-15 03:54:19 +0000 UTC) !
cc the namespace from the provided object "kube-system" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=kube-system' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation.
related fix:
No I don't think that's the fix for this (that is just a little cleanup). Actually I think we have to delete namespace parameter in line : Because before , the will have no actually effect. But now with the change of , it will have namespace : at the end of the command. But the namespace in yaml file is which is different from . We should not have parameter when applying from file because this test didn't have before, right? Related PR:
/assign

Related discussion:
text: } defer monitoring.CleanupDescriptors(gcmService, projectID) <del> err = monitoring.CreateAdapter(tc.framework.Namespace.ObjectMeta.Name, monitoring.AdapterDefault) </del> <ins> err = monitoring.CreateAdapter(monitoring.AdapterDefault) </ins> if err != nil { framework.Failf("Failed to set up: %v", err) } <del> defer monitoring.CleanupAdapter(tc.framework.Namespace.ObjectMeta.Name, monitoring.AdapterDefault) </del> <ins> defer monitoring.CleanupAdapter(monitoring.AdapterDefault) </ins> // Run application that exports the metric err = createDeploymentToScale(tc.framework, tc.kubeClient, tc.deployment, tc.pod)
Code change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig autoscaling Looks like it just started happening today (@ 2020-09-15 03:54:19 +0000 UTC) !
cc the namespace from the provided object "kube-system" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=kube-system' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation.
related fix:
No I don't think that's the fix for this (that is just a little cleanup). Actually I think we have to delete namespace parameter in line : Because before , the will have no actually effect. But now with the change of , it will have namespace : at the end of the command. But the namespace in yaml file is which is different from . We should not have parameter when applying from file because this test didn't have before, right? Related PR:
/assign

Related discussion:
text: // CreateAdapter creates Custom Metrics - Stackdriver adapter // adapterDeploymentFile should be a filename for adapter deployment located in StagingDeploymentLocation <del> func CreateAdapter(namespace, adapterDeploymentFile string) error { </del> <ins> func CreateAdapter(adapterDeploymentFile string) error { </ins> // A workaround to make the work on GKE. GKE doesn't normally allow to create cluster roles, // which the adapter deployment does. The solution is to create cluster role binding for // cluster-admin role and currently used service account. <del> err := createClusterAdminBinding(namespace) </del> <ins> err := createClusterAdminBinding() </ins> if err != nil { return err }
Code change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig autoscaling Looks like it just started happening today (@ 2020-09-15 03:54:19 +0000 UTC) !
cc the namespace from the provided object "kube-system" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=kube-system' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation.
related fix:
No I don't think that's the fix for this (that is just a little cleanup). Actually I think we have to delete namespace parameter in line : Because before , the will have no actually effect. But now with the change of , it will have namespace : at the end of the command. But the namespace in yaml file is which is different from . We should not have parameter when applying from file because this test didn't have before, right? Related PR:
/assign

Related discussion:
text: if err != nil { return err } <del> stat, err := framework.RunKubectl(namespace, "create", "-f", adapterURL) </del> <ins> stat, err := framework.RunKubectl("", "create", "-f", adapterURL) </ins> framework.Logf(stat) return err } <del> func createClusterAdminBinding(namespace string) error { </del> <ins> func createClusterAdminBinding() error { </ins> stdout, stderr, err := framework.RunCmd("gcloud", "config", "get-value", "core/account") if err != nil { framework.Logf(stderr)
Code change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig autoscaling Looks like it just started happening today (@ 2020-09-15 03:54:19 +0000 UTC) !
cc the namespace from the provided object "kube-system" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=kube-system' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation.
related fix:
No I don't think that's the fix for this (that is just a little cleanup). Actually I think we have to delete namespace parameter in line : Because before , the will have no actually effect. But now with the change of , it will have namespace : at the end of the command. But the namespace in yaml file is which is different from . We should not have parameter when applying from file because this test didn't have before, right? Related PR:
/assign

Related discussion:
text: } serviceAccount := strings.TrimSpace(stdout) framework.Logf("current service account: %q", serviceAccount) <del> stat, err := framework.RunKubectl(namespace, "create", "clusterrolebinding", ClusterAdminBinding, "--clusterrole=cluster-admin", "--user="+serviceAccount) </del> <ins> stat, err := framework.RunKubectl("", "create", "clusterrolebinding", ClusterAdminBinding, "--clusterrole=cluster-admin", "--user="+serviceAccount) </ins> framework.Logf(stat) return err }
Code change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig autoscaling Looks like it just started happening today (@ 2020-09-15 03:54:19 +0000 UTC) !
cc the namespace from the provided object "kube-system" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=kube-system' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation.
related fix:
No I don't think that's the fix for this (that is just a little cleanup). Actually I think we have to delete namespace parameter in line : Because before , the will have no actually effect. But now with the change of , it will have namespace : at the end of the command. But the namespace in yaml file is which is different from . We should not have parameter when applying from file because this test didn't have before, right? Related PR:
/assign

Related discussion:
text: } // CleanupAdapter deletes Custom Metrics - Stackdriver adapter deployments. <del> func CleanupAdapter(namespace, adapterDeploymentFile string) { stat, err := framework.RunKubectl(namespace, "delete", "-f", adapterDeploymentFile) </del> <ins> func CleanupAdapter(adapterDeploymentFile string) { stat, err := framework.RunKubectl("", "delete", "-f", adapterDeploymentFile) </ins> framework.Logf(stat) if err != nil { framework.Logf("Failed to delete adapter deployments: %s", err)
Code change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig autoscaling Looks like it just started happening today (@ 2020-09-15 03:54:19 +0000 UTC) !
cc the namespace from the provided object "kube-system" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=kube-system' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation.
related fix:
No I don't think that's the fix for this (that is just a little cleanup). Actually I think we have to delete namespace parameter in line : Because before , the will have no actually effect. But now with the change of , it will have namespace : at the end of the command. But the namespace in yaml file is which is different from . We should not have parameter when applying from file because this test didn't have before, right? Related PR:
/assign

Related discussion:
text: if err != nil { framework.Logf("Failed to delete adapter deployment file: %s", err) } <del> cleanupClusterAdminBinding(namespace) </del> <ins> cleanupClusterAdminBinding() </ins> } <del> func cleanupClusterAdminBinding(namespace string) { stat, err := framework.RunKubectl(namespace, "delete", "clusterrolebinding", ClusterAdminBinding) </del> <ins> func cleanupClusterAdminBinding() { stat, err := framework.RunKubectl("", "delete", "clusterrolebinding", ClusterAdminBinding) </ins> framework.Logf(stat) if err != nil { framework.Logf("Failed to delete cluster admin binding: %s", err)
Code change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig autoscaling Looks like it just started happening today (@ 2020-09-15 03:54:19 +0000 UTC) !
cc the namespace from the provided object "kube-system" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=kube-system' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation.
related fix:
No I don't think that's the fix for this (that is just a little cleanup). Actually I think we have to delete namespace parameter in line : Because before , the will have no actually effect. But now with the change of , it will have namespace : at the end of the command. But the namespace in yaml file is which is different from . We should not have parameter when applying from file because this test didn't have before, right? Related PR:
/assign

Related discussion:
text: } defer CleanupDescriptors(gcmService, projectID) <del> err = CreateAdapter(f.Namespace.Name, adapterDeployment) </del> <ins> err = CreateAdapter(adapterDeployment) </ins> if err != nil { framework.Failf("Failed to set up: %s", err) } <del> defer CleanupAdapter(f.Namespace.Name, adapterDeployment) </del> <ins> defer CleanupAdapter(adapterDeployment) </ins> _, err = kubeClient.RbacV1().ClusterRoleBindings().Create(context.TODO(), HPAPermissions, metav1.CreateOptions{}) if err != nil {
Code change:
/kind failing-test <!-- If this is a flake, please add: /kind flake --/sig autoscaling Looks like it just started happening today (@ 2020-09-15 03:54:19 +0000 UTC) !
cc the namespace from the provided object "kube-system" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=kube-system' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation. the namespace from the provided object "custom-metrics" does not match the namespace "horizontal-pod-autoscaling-830". You must pass '--namespace=custom-metrics' to perform this operation.
related fix:
No I don't think that's the fix for this (that is just a little cleanup). Actually I think we have to delete namespace parameter in line : Because before , the will have no actually effect. But now with the change of , it will have namespace : at the end of the command. But the namespace in yaml file is which is different from . We should not have parameter when applying from file because this test didn't have before, right? Related PR:
/assign

Related discussion:
text: defer CleanupDescriptors(gcmService, projectID) // Both deployments - for old and new resource model - expose External Metrics API. <del> err = CreateAdapter(f.Namespace.Name, AdapterForOldResourceModel) </del> <ins> err = CreateAdapter(AdapterForOldResourceModel) </ins> if err != nil { framework.Failf("Failed to set up: %s", err) } <del> defer CleanupAdapter(f.Namespace.Name, AdapterForOldResourceModel) </del> <ins> defer CleanupAdapter(AdapterForOldResourceModel) </ins> _, err = kubeClient.RbacV1().ClusterRoleBindings().Create(context.TODO(), HPAPermissions, metav1.CreateOptions{}) if err != nil {
Code change:
Which jobs are flaking: https://k8s- Which test(s) are flaking: Services should have session affinity timeout work for service with type clusterIP Services should have session affinity timeout work for NodePort service We have other flaky cases, like , that should also bu resolved. But cases also run in , so I suggest we solve this problem first. Testgrid link: https://k8s- Reason for failure: In ipvs mode, we set session affinity timeout as 125s, the test case is: run host command to send a request, mark returned hostName 125s another request, if return different hostName, test succed. I think the reason is, in the second request, ipvs connection may still in sessionAffinity, send another request will result in seffinity restart count, eventually result in this test case flaky.
/sig network /area ipvs
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign /remove-triage unresolved
This keeps failing https://k8s-

Related discussion:
text: if hosts.Len() > 1 { return } <del> time.Sleep(time.Duration(svcSessionAffinityTimeout) * time.Second) </del> <ins> // In some case, ipvs didn't deleted the persistent connection after timeout expired, // use 'ipvsadm -lnc' command can found the expire time become '13171233:02' after '00:00' // // pro expire state       source             virtual            destination // TCP 00:00  NONE        10.105.253.160:0   10.105.253.160:80  10.244.1.25:9376 // // pro expire state       source             virtual            destination // TCP 13171233:02 NONE        10.105.253.160:0   10.105.253.160:80  10.244.1.25:9376 // // And 2 seconds later, the connection will be ensure deleted, // so we sleep 'svcSessionAffinityTimeout+5' seconds to avoid this issue. // TODO: figure out why the expired connection didn't be deleted and fix this issue in ipvs side. time.Sleep(time.Duration(svcSessionAffinityTimeout+5) * time.Second) </ins> } } framework.Fail("Session is sticky after reaching the timeout")
Code change:
Inspired from Our default Filter plugins have the following order: IIUC, this order was chosen to have the fastest Filters or the most probability of reporting Unschedulable first. Arguably, some are pretty much equivalent and could be reordered. The major problem with this order is that plugin is almost at the beginning. This plugin only reports . A Node that fails this plugin will be evaluated during preemption. But perhaps this Node doesn't satisfy other UnschedulabeAndUnresolvable requirements (taints, node selectors, nodeaffinity). Theoretically, having those Filters run first could improve preemption latency. The only open question is whether or not the ordering we have today is an API guarantee. I believe it's not (at least in component config), because the only way to change the ordering of Plugins is disabling all of them first. Decided order: /sig scheduling
for comment
and :)
Even we changed the order of plugins, the framework.RunFilterPlugins still exits early when returned by plugin. So should we change the current behavior to run the filter plugins until there is one plugin returned ?
That is correct, and that's what it should be.
No, that's what the original conversation suggested and it's likely not ideal in the average case.
+1 to reordering. Taints, affinity, node name can all be executed before checking for resource fit. No, it is not.
+1. Lightweight plugins that may return status can be moved ahead of other plugins that only return status.
FYI: from who also had this concern: So how about , is it also a good candidate to be moved ahead of ? NodeAffinity and NodeSelector both incorporated in , I'm pretty sure NodeSelector logic is simply, but not 100% sure NodeAffinity logic falls into the category of "lightweight".
Let me propose an order, for extra clarity:
internally composes and invokes , which IMO is a bit more expensive than . should be cheaper than . So my 2 cents is:
Both proposals are fine by me.
/triage accepted /help /good-first-issue
/assign
I want to help here :)
/remove-help

Related discussion:
text: Filter: &schedulerapi.PluginSet{ Enabled: []schedulerapi.Plugin{ {Name: nodeunschedulable.Name}, <del> {Name: noderesources.FitName}, </del> {Name: nodename.Name}, <del> {Name: nodeports.Name}, </del> <ins> {Name: tainttoleration.Name}, </ins> {Name: nodeaffinity.Name}, <ins> {Name: nodeports.Name}, {Name: noderesources.FitName}, </ins> {Name: volumerestrictions.Name}, <del> {Name: tainttoleration.Name}, </del> {Name: nodevolumelimits.EBSName}, {Name: nodevolumelimits.GCEPDName}, {Name: nodevolumelimits.CSIName},