jiebi/CodeConvo huggingface dataset:
Change:
} if deleted { klog.InfoS("Removed real server from graceful delete real server list", "realServer", name) <del> q.remove(rs) </del> <ins> delete(q.list, rs.String()) </ins> } } return success

Discussion:
! no panic Kubernetes version (use ): k8s 1.16
/sig Network
Could you fix this? I think the function needs a lock while being executed.
/triage accepted /good-first-issue todo: add a lock around the body of this function: Similar to
/assign
Oh I see, thank you for letting me know, I'll keep that in mind going forward. :)
Anyone actually on this? It seems like a good fix to have for 23 and maybe backport
I'll have a try.
There is a reproducer here
Oops, I just peeked at the time of the pull request and not realized that you've got such deep conversation.
/remove-good-first-issue /unassign
/assign
hi ! someone work on this now? I would like to try it.
Yes, working on it currently.
are you still planning to give this a shot?
Is there no one working on this? If so, I'd submit a PR for it this week. :)
Change:
initialConfig.ContainerLogMaxSize = testContainerLogMaxSize }) <del> ginkgo.It("should be rotated and limited to a fixed amount of files", func(ctx context.Context) { </del> <ins> var logRotationPod *v1.Pod ginkgo.BeforeEach(func() { </ins> ginkgo.By("create log container") pod := &v1.Pod{ ObjectMeta: metav1.ObjectMeta{

Discussion:
Device Plugin [Feature:DevicePluginProbe][NodeFeature:DevicePluginProbe][Serial] DevicePlugin [Serial] [Disruptive] Can schedule a pod that requires a device It appears a bit flaky on testgrid, but more recently been failing more often No response example - No response /sig node
/cc
/triage accepted /assign /priority important-soon
I ran this test locally 15 times back to back and did not run into this failure. The test passed locally. I suspect this to be a case where pod cleanup is not happening properly. In this test, we are relying on the number of PodResources and based on the error it looks like we have an addtional pod running other than the two expected pods (device plugin pod and test pod requesting device) but can't be 100% sure because we don't have enough logs to support that claim. Going to add more logs to expose output obtained from the podresource API endpoint.
Change:
// First return value indicates whether a matching pod exists on a node that matches the topology key, // while the second return value indicates whether a matching pod exists anywhere. // TODO: Do we really need any pod matching, or all pods matching? I think the latter. <del> func (c *PodAffinityChecker) anyPodMatchesPodAffinityTerm(pod *v1.Pod, allPods []*v1.Pod, node *v1.Node, term *v1.PodAffinityTerm) (bool, bool, error) { </del> <ins> func (c *PodAffinityChecker) anyPodMatchesPodAffinityTerm(pod *v1.Pod, pods []*v1.Pod, nodeInfo *schedulercache.NodeInfo, term *v1.PodAffinityTerm) (bool, bool, error) { </ins> if len(term.TopologyKey) == 0 { return false, false, fmt.Errorf("empty topologyKey is not allowed except for PreferredDuringScheduling pod anti-affinity") }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --It is not a secret that . In my opinion the main reason for the slowness is the flexibility of the inter-pod affinity/anti-affinity rules. However, in most practical scenarios users do not need all the flexibility. For example, people often do not use arbitrary labels in topology key of the affinity rules. They often use node, zone, or region as the topology. Node in particular is used often. That's why I am proposing a fast path for the case that topology key is Node. Today, the affinity/anti-affinity predicate does not have any distinction for topology keys and in the cluster regardless. The logic should recognize "" and scan only pods on the same node for this topology key. Is this a BUG REPORT or FEATURE REQUEST?: FEATURE REQUEST /kind feature /sig scheduling cc/
ref/
/assign
GitHub didn't allow me to assign the following users: misterikkit. Note that only can be assigned. <detailsIn response to : /assign 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
/cc
We found some other simple optimizations that had a significant impact on the affinity predicate. I will upload PRs for those as well.
Reopening this as the performance of anti-affinity still doesn't seem to be satisfactory enough on large clusters (i.e 5k nodes) - and it's causing them to fail to startup. Ref: issue I can help with evaluating any performance improvements if needed.
The change sent improved performance of the predicate, but apparently it is not enough to make our large scale scalability tests happy.
This issue is not about general performance improvment of affinity/anti-affinity. It was to implement a particular improvment which is already implemented. There are other performance improvement issues. I am going to close this one.
Sounds good. Thanks.
How come with kops 1.10.0 I still see all kube-dns pods on the same node because the kube-dns deployment doesn't specify any anti-affinity rule?
I think you are correct. you can double-check with the option to . I have a v1.9 cluster in front of me, and kube-dns has no affinity rules. (I didn't use kops though)
Change:
// Find all sibling pods in the service and post to their /write handler. func contactOthers(state *State) { <ins> var ( versionInfo *version.Info err         error ) </ins> sleepTime := 5 * time.Second // In large cluster getting all endpoints is pretty expensive. // Thus, we will limit ourselves to send on average at most 10 such

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: N/A Which test(s) are failing: [] [sig-node] PreStop should call prestop when killing a pod [Conformance] Since when has it been failing: N/A Testgrid link: N/A Reason for failure: When spawning a Pod, it's container might start before all its networking plumbing has been completed. Thus, if the container tests / needs its network connectivity, it mgiht fail. The ` image tries to connect to the Kubernetes API, but if it cannot, the Pod will end up in an Error state. Retrying the Kubernetes API connection will avoid this issue. Anything else we need to know:
/sig node
/remove-sig node /sig testing
Change:
var _ = utils.SIGDescribe("CSI mock volume", func() { type testParameters struct { <del> attachable      bool </del> <ins> disableAttach   bool </ins> attachLimit     int registerDriver  bool podInfoVersion  *string

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: in Which test(s) are failing: Since when has it been failing: 2019-02-27 () -- since it was Testgrid link: Reason for failure: Timeout: Anything else we need to know: /kind failing-test /sig storage /priority important-soon /milestone v1.14 cc
cc Could you help with this please?
/assign
Neither of the failing tests mentioned in this issue are present in testgrid anymore. is all clear
Change:
endpoint:             "/var/log/kubelet/plugins/myplugin/csi.sock", versions:             []string{"0.2.0", "v1.2.3"}, foundInDeprecatedDir: true, <del> shouldFail:           true, </del> <ins> shouldFail:           false, </ins> }, { pluginName:           "test.plugin",

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!--What happened: CSI allows 0.x drivers only in the deprecated kubelet plugin dir. CSI allows 1.x drivers only in the new kubelet plugin dir. If a driver implements both 0.x and 1.x (which is unlikely since the side car containers do not support this), kubelet requires the driver live in new kubelet plugin dir. So CSI drivers that implement both 0.x and 1.x if they want a seamless transition between k8s 1.12 to 1.13 would need to deploy in both old and new dir. What you expected to happen: argues that this is adding churn for CSI authors. He recommends allowing any driver that implements 0.x (even if it implements 1.x) to use either new or old (not just new). /milestone v1.13 If release team approves, PR is small and I can get prepare it pretty quickly. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
discussed in the burndown meeting, please go ahead and prepare the PR
/sig storage /priority critical-urgent /milestone v1.13
we need to wait for a fix for this before lifting code freeze
Change:
} else if vm.InstanceView != nil && vm.InstanceView.PlatformFaultDomain != nil { // Availability zone is not used for the node, falling back to fault domain. failureDomain = strconv.Itoa(int(*vm.InstanceView.PlatformFaultDomain)) <ins> } else { err = fmt.Errorf("failed to get zone info") klog.Errorf("GetZoneByNodeName: got unexpected error %v", err) ss.deleteCacheForNode(name) return cloudprovider.Zone{}, err </ins> } return cloudprovider.Zone{

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: The cluster is release-1.16. When a VMSS is manually scaled up, some pointers in of the newly created nodes are nil. Here's the list of the missing ones: PlatformUpdateDomain PlatformFaultDomain - - - The strikeouts mean they are missing but we don't focus on them. What you expected to happen: These pointers are not supposed to be nil. How to reproduce it (as minimally and precisely as possible): a cluster with VMSS, k8s version release-1.16 and ccm enabled. up the VMSS. Anything else we need to know?: Note that this issue only happens when ccm is enabled. Environment: Kubernetes version (use ): 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:
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /area provider-azure 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
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /area provider-azure 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
/sig cloud-provider /area provider/azure /milestone v1.17
Change:
set +o nounset set +o errexit } <ins> run_kubectl_diff_same_names() { set -o nounset set -o errexit create_and_use_new_namespace kube::log::status "Test kubectl diff with multiple resources with the same name" output_message=$(KUBECTL_EXTERNAL_DIFF=find kubectl diff -Rf hack/testdata/diff/) kube::test::if_has_string "${output_message}" 'v1.Pod:.*.test' kube::test::if_has_string "${output_message}" 'apps.v1.Deployment:.*.test' kube::test::if_has_string "${output_message}" 'v1.ConfigMap:.*.test' kube::test::if_has_string "${output_message}" 'v1.Secret:.*.test' set +o nounset set +o errexit } </ins>

Discussion:
What happened: I get a diff, when I specify a file directly, but on recursive mode, no diff is shown anymore: What you expected to happen: Recursive mode should work How to reproduce it (as minimally and precisely as possible): Have a bunch of YAML manifest, but with name collisions, e.g. Service , Deployment , etc Anything else we need to know?: I think the problem is that all objects have the same name, which should not be a problem per se. Only heapster-binding has a different name, and looking at the generated temp files, only and are present: Environment: Kubernetes version (use ): $ kubectl version --short Client Version: v1.13.0 Server Version: v1.13.0 <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig cli
I think the files are overwriting each other?
Yeah, good catch, I'll try to fix that asap
Thanks! By the way, very nice work with dry-run and diff. I was waiting for this.
Feel free to look at the PR and give your opinion!
Change:
ginkgo.It("should be able to preserve UDP traffic when server pod cycles for a LoadBalancer service on the same nodes", func(ctx context.Context) { // requires cloud load-balancer support <del> e2eskipper.SkipUnlessProviderIs("gce", "gke", "aws", "azure") </del> <ins> e2eskipper.SkipUnlessProviderIs("gce", "gke", "azure") </ins> ns := f.Namespace.Name nodes, err := e2enode.GetBoundedReadySchedulableNodes(ctx, cs, 1) framework.ExpectNoError(err)

Discussion:
When running the e2e tests on AWS, the following two tests are failing: with the stated cause being: these tests were with Expected the tests to pass Run the loadbalancer test suite on AWS While investigating the root cause of these failures, i cam across this function in the cloud-provider-aws: This function checks to ensure that a specific annotation has been applied to the Service object to determine if it is an NLB. The test in question creates the Service object with no annotations placed upon it, this in turn causes the test to fail. This confirms the need for the user to add the annotation. It is a continuation of a discussion that started in the SIG Cloud Provider meeting from 15 Feb 2023. <detailsi don't have a live cluster for this anymore, but it was version 1.26.1 </details<detailsAWS </details<details</details<details</details<details</details<details</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
/sig network /sig cloud-provider
when exploring this issue, i noticed we have this function in a different load balancer test: that function appears to have some specific logic for adding/removing annotations depending on the cloud provider. i thought this might be a place we could also use for AWs and the new tests, but i'm not sure if it is appropriate.
the test should be as much agnostic as possible, theoretically we tried to remove all the checks for cloud providers but Adding annotations and supporting all permutations on each cloud provider will be hard to support in the long term. If AWS doesn't support it we just can skip them in AWS
/assign
thanks , agreed on all points
please go ahead and tag me
Change:
"fmt" "net" "strings" <ins> "sync" </ins> "syscall" "github.com/vishvananda/netlink"

Discussion:
I gathered e2e test results of suite for last 100 runs. The following is the list of flaky tests. Some might not be related to . I will start with the service tests. Any help would be appreciated. Detail list: Jenkins project:
cc/ Cluster team is working on to make kubenet default. Once we switch this to production, we don't need to restart docker to configure cbr0.
After a bunch of PRs got merged, the kubenet suite is much more stable. One more known flake can be fixed by I will post new flake tests here.
Just bump into a new failure: One of the nodes () got panic: Looks like it crashed at shaper reset.: Can you take a look?
Change:
endpoint: %s`, listener.Addr().String())), os.FileMode(0755)); err != nil { t.Fatal(err) } <ins> testAPIServerTracing(t, listener, []string{ "--tracing-config-file=" + tracingConfigFile.Name(), "--egress-selector-config-file=" + egressSelectorConfigFile.Name(), }, ) } func testAPIServerTracing(t *testing.T, listener net.Listener, apiserverArgs []string) { defer featuregatetesting.SetFeatureGateDuringTest(t, utilfeature.DefaultFeatureGate, genericfeatures.APIServerTracing, true)() traceFound := make(chan struct{}) defer close(traceFound) srv := grpc.NewServer() traceservice.RegisterTraceServiceServer(srv, &traceServer{ traceFound: traceFound, filterFunc: containsNodeListSpan}) go srv.Serve(listener) defer srv.Stop() </ins> // Start the API Server with our tracing configuration testServer := kubeapiservertesting.StartTestServerOrDie(t, kubeapiservertesting.NewDefaultTestServerOptions(), <del> []string{"--tracing-config-file=" + tracingConfigFile.Name()}, </del> <ins> apiserverArgs, </ins> framework.SharedEtcd(), ) defer testServer.TearDownFn()

Discussion:
While trying to enable API Server Tracing while using k3s, the API Server component crashes. The only way to avoid this crash is to disable egress selectors in k3s entirely. I originally opened an issue in the k3s repo (see ), and we determined that the issue seems to be an assumption that a dialer will always be returned if there's no error, but in this case there's no grpc egress configured so is returning and causing a panic at API Server Tracing to function properly. Please see the linked k3s issue for a repro case; However, I believe the minimal setup for this would be to configure cluster egress without defining a grpc egress selector and then attempting to enable API server tracing. panic stack trace -- contents of egress selector config file in direct mode- contents of egress selector config in 'agent' mode - contents of api server tracing config file -- <details25.2+k3s1 </details<detailsDigital Ocean Droplet </details<details</details<details</details<details</details<details</details
/sig instrumentation
/assign /triage accepted Thanks
Change:
<ins> # This Dockerfile will build an image that is configured # to run Fluentd with an Elasticsearch plug-in and the # provided configuration file. # TODO(satnam6502): Use a lighter base image, e.g. some form of busybox. # The image acts as an executable for the binary /usr/sbin/td-agent. # Note that fluentd is run with root permssion to allow access to # log files with root only access under /var/lib/docker/containers/* # Please see http://docs.fluentd.org/articles/install-by-deb for more # information about installing fluentd using deb package. FROM ubuntu:14.04 MAINTAINER Satnam Singh "satnam@google.com" # Ensure there are enough file descriptors for running Fluentd. RUN ulimit -n 65536 # Install prerequisites. RUN apt-get update &&  apt-get install -y curl &&  apt-get install -y -q libcurl4-openssl-dev make &&  apt-get clean # Install Fluentd. RUN /usr/bin/curl -L http://toolbelt.treasuredata.com/sh/install-ubuntu-trusty-td-agent2.sh | sh # Change the default user and group to root. # Needed to allow access to /var/log/docker/... files. RUN sed -i -e "s/USER=td-agent/USER=root/" -e "s/GROUP=td-agent/GROUP=root/" /etc/init.d/td-agent # Install the Elasticsearch Fluentd plug-in. RUN /usr/sbin/td-agent-gem install fluent-plugin-elasticsearch # Copy the Fluentd configuration file. COPY td-agent.conf /etc/td-agent/td-agent.conf # Copy a script that determines the name of the host machine # and then patch the Fluentd configuration files and then # run Fluentd in the foreground. ADD run.sh /run.sh # Always run the this setup script. ENTRYPOINT ["/run.sh"] </ins>

Discussion:
After PR , I did a bit experiments on kube-dns graceful termination and got some unintended result as below: I guess it is because the other container was terminated before . DNS query from clients failed because is the actual connection point. After a bit discussion with and two solutions for this are: another program wrap up the dnsmasq and capture the SIGTERM signal. out a way to modify the sig mask of process without touching the original codes.
Something I have been meaning to try: Put in Dockerfile Build and push image We should deliver SIGCONT rather than SIGTERM. I did a quick test and it seems to work. Otherwise trapping SIGTERM in the shell and ignoring it is well documented... , Zihong Zheng wrote:
Thanks, I will take a look and test these.
Change:
}, { "ImportPath": "github.com/docker/spdystream", <del> "Rev": "29e1da2890f60336f98d0b3bf28b05070aa2ee4d" </del> <ins> "Rev": "e9bf9912b85eec0ed6aaf317808a0eab25e3ca43" </ins> }, { "ImportPath": "github.com/elazarl/go-bindata-assetfs",

Discussion:
Hit this while :
cc/ Andy can you take a look at this failure?
looking now
Working with on a fix
Proposed fix:
Change:
v1.ResourceMemory: resource.MustParse("15Mi"), }, Limits: v1.ResourceList{ <del> v1.ResourceMemory: resource.MustParse("15Mi"), </del> <ins> v1.ResourceMemory: resource.MustParse("35Mi"), </ins> }, }

Discussion:
E2eNode Suite: [It] [sig-node] [NodeConformance] Containers Lifecycle when a pod is terminating because its liveness probe fails should execute readiness probe while in preStop, but not liveness [NodeConformance] Has been flaking sinc Testcase addition in It has been constantly failing in our internal CI on /sig node
^^
this is strange, I don't understand why the hook is never executed... is it a matter of waiting more for this to happen? What's the performance of these ppc runners?
On our ppc node it seems to a OOM error. I see the container related to testcase being killed with OOM message. request you to point me out if there is any memory requirement to run the e2e-node suite. Also, is there anything related to this particular test that consumes more memory?
Interesting... not that I knew. These are small containers using BusyBox images, I don't think we can do much smaller than that. Do you have memory pressure on the node? Because we don't set any resource limit on our Pods. Maybe we should try to reduce the env variable?
I shall try reducing the as you suggested. But, the test fails with OOM messages even when run alone (not as part of the complete suite)
Any clue on why we are experiencing OOM error only for this testcase? I am trying to compare pod spec to see if this is defined differently.
I don't think we have anything special in the Pod spec... I might try to replicate exactly one test that works.
cc
I think this is still failing. /reopen
Reopened this issue. <detailsIn response to : I think this is still failing. 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
A short preStop hook period looks like an issue. I'll post a PR.
/assign /triage accepted
can we close this?
Yes, I think so as there is no failure recently. /close
Closing this issue. <detailsIn response to : can we close 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