jiebi/CodeConvo huggingface dataset:
Change:
{ description: "notready sandboxes without containers for deleted pods should be garbage collected.", sandboxes: []sandboxTemplate{ <del> makeGCSandbox(pods[2], 0, runtimeapi.PodSandboxState_SANDBOX_NOTREADY, false), </del> <ins> makeGCSandbox(pods[2], 0, runtimeapi.PodSandboxState_SANDBOX_NOTREADY, false, 0), </ins> }, containers: []containerTemplate{}, remain:     []int{},

Discussion:
kubernetes pre-submit unit tests for pass some times and fails some times causing the flakiness. Here is one such failure https://k8s- Passing: Failing: cc
Yep, I'm checking with this
Sorry for introducing a flakiness. Sent out the fix in .
/assign
Dup of . /close

https://k8s- Failed: TestSandboxGC {kuberuntime}
https://k8s- Failed: TestSandboxGC {kuberuntime}
/assign
Should've been fixed by
Change:
var prober *etcd3ProberMonitor clientErr := fmt.Errorf("etcd client connection not yet established") <del> go wait.PollUntil(time.Second, func() (bool, error) { newProber, err := newETCD3ProberMonitor(c) </del> <ins> go wait.PollImmediateUntil(time.Second, func() (bool, error) { </ins> lock.Lock() defer lock.Unlock() <ins> newProber, err := newETCD3ProberMonitor(c) </ins> // Ensure that server is already not shutting down. select { case <-stopCh:

Discussion:
flakes several times recently /kind flake /sig api-machinery
This failure occurs for all tests in as mentioned in The description shows flaking.
/cc
/cc I remember someone tried to fix it some time ago,
/assign for context of /triage accepted
All of them fail with "connection not yet established" There is something odd in these tests, since we mock the KV but we create a "real" etcd process, I wonder if we flake on trying to connect to the real etcd process or there is some weird race because of that
do you want to try with ?
Change:
return fmt.Errorf("failed to watch %s, err: %v", path, err) } case mode&os.ModeSocket != 0: <del> w.wg.Add(1) go func() { defer w.wg.Done() w.fsWatcher.Events <- fsnotify.Event{ Name: path, Op:   fsnotify.Create, } }() </del> <ins> event := fsnotify.Event{ Name: path, Op:   fsnotify.Create, } //TODO: Handle errors by taking corrective measures if err := w.handleCreateEvent(event); err != nil { klog.Errorf("error %v when handling create event: %s", err, event) } </ins> default: klog.V(5).Infof("Ignoring file %s with mode %v", path, mode) }

Discussion:
What happened: A race condition in the plugin watcher might happen when a is created, started and immediately stopped and cleaned up. If executed several times, the unit test will expose this issue. The PR addressed part of the problem by serializing the handling of CREATE and DELETE events. However, a race might still happen in the function. describes in detail the problem. How to reproduce it (as minimally and precisely as possible): /sig storage /sig node
/assign
Change:
Name:      daemonSetName, }, Spec: apps.DaemonSetSpec{ <ins> Selector: &metav1.LabelSelector{ MatchLabels: labelSet, }, </ins> Template: v1.PodTemplateSpec{ ObjectMeta: metav1.ObjectMeta{ Labels: labelSet,

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: At least 2019-01-07 Testgrid link: Reason for failure: /sig apps /sig cluster-lifecycle
cc
/assign
Change:
} apt-get-install() { <ins> local -r packages=( $@ ) installed=true for package in "${packages[@]}"; do if ! dpkg -s "${package}" &>/dev/null; then installed=false break fi done if [[ "${installed}" == "true" ]]; then echo "== ${packages[@]} already installed, skipped apt-get install ${packages[@]} ==" return fi apt-get-update </ins> # Forcibly install packages (options borrowed from Salt logs). until apt-get -q -y -o DPkg::Options::=--force-confold -o DPkg::Options::=--force-confdef install $@; do echo "== install of packages $@ failed, retrying =="

Discussion:
I noticed that there is a huge regression on node bootup since Wednesday last couple of days: Bad one: vs. good one: Please note that the issue is not related to any kubernetes component. The node hasn't run salt client yet. This explains a lot of node not ready issue we have lately. cc/
cc/
Whoa, it shouldn't even be running at all. That implies someone a package recently.
I didn't see any new package is , and the entire package size is the same. :-(
Can you dump /var/log/apt.history (I think it is) into here?
Sorry, . Hmm. I don't see anything new on a recent-ish head node, either, but YMMV.
Yes, just about to do it ... Here you are, and please note that it is from a different node with the same bad symptom:
Yeah, no issue there. Oh. Hm. Sorry, I forgot the one directly in .
Wait. The one in configure-vm is new, it's from , and we need to take it out.
Oh no - so sorry :-( does add an apt-get update to configure-vm. But you are installing bridge-utils from apt, so I thought it was correct to apt-get update first. I can easily remove the apt-get-update and add it back into the AWS version instead. In my experience, crazy-slow apt-get problems are either due to an IPv6 address being served to an IPv4 only host, or getting a bad mirror. Is there a GCE internal mirror? Could also be the gluster repo as well - not necessarily the debian repo.
Probably the bestest thing would be to make sure bridge-utils is on the base image, only apt-get-install bridge-utils if brctl is not available, and run apt-get-update as part of apt-get-install only once per script invocation. But this isn't actually fixing the problem. Something is seriously wrong if an apt-get update takes 12 minutes.
is actually built-in on (the later is a no-op, sorry). I went through an effort at some point to make sure that never needed to or anything, because we were having troubles like this.
I can work up a PR that will probably work for all parties.
Yes, that is the root cause and we want to remove all external dependencies at bootup time. Assign this to
Thanks & sorry again to all.
Change:
} firstRunning.Wait() <ins> sendSignals() </ins> fakeFilter.wait() firstRunning.Add(concurrentRequests) for i := 0; i < concurrentRequests; i++ { go func() { defer wg.Done()

Discussion:
Testgrid doesn't load kubernetes/test-infra From: /sig api-machinery
/assign /triage accepted
Yes. It looks like a bug. There are many calls to , and they are not all guaranteed to happen before the second . I will revise.
Change:
importpath = "k8s.io/kubernetes/pkg/scheduler/framework/v1alpha1", visibility = ["//visibility:public"], deps = [ <ins> "//pkg/scheduler/api:go_default_library", </ins> "//pkg/scheduler/apis/config:go_default_library", "//pkg/scheduler/internal/cache:go_default_library", "//pkg/scheduler/util:go_default_library",

Discussion:
What would you like to be : a default normalize score function in the scheduling framework. the plugin and log an error when the normalizing phase returns an invalid range of scores. Why is this needed: Per discussion in , we should enforce the range of score returned by the scoring plugin. /sig scheduling /priority important-soon /assign
Change:
// to set values and determine whether its allowed AdmissionControl      admission.Interface CorsAllowedOriginList []string <ins> HSTSDirectives        []string </ins> // FlowControl, if not nil, gives priority and fairness to request handling FlowControl utilflowcontrol.Interface

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add the "Strict-Transport-Security" header to the API server responses. Why is this needed: Nessus scanner treats this as a Medium Risk in kubernetes 1.18.10.
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 api-machinery
/remove-sig api-machinery /sig auth
Change:
t.Fatalf("bad cidr: %v", err) } cfg.ExtraConfig.ServiceIPRange = *cidr <ins> cfg.GenericConfig.PublicAddress = netutils.ParseIPSloppy("2001:db8::10") </ins> _, secCidr, err := netutils.ParseCIDRSloppy(secondaryServiceCIDR) if err != nil {

Discussion:
Clusters created with kubeadm using DualStack are not able to work, because CoreDNS pods never get ready Seeing one failed job logs It seems that the pod is "waiting for the kubernetes service"?? coredns version seems the same as in the working jobs CoreDNS pod should be ready Instal a Dual-stack cluster using master with kubeadm (or kind ) ! It started to fail on Oct12 <details</details<details</details<details</details<details</details<details</details<details</details
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
/cc I didn't notice it was failing for more than 1 month :facewithhead_bandage: I didn't have time to dig into it yet, but this PR landed just that day how is that the pods running has the version 1.8.4 but the PR seems to update kubeadm to 1.8.6?
Looking into this today. The error from CoreDNS should only happen when the kubernetes plugin fails to sync with the Kubernetes API, either because it can’t connect, or it can’t sync the lists of services/endpointslices. There were changes and fixes to the API connection code, so it could be a regression.
Actually no. The changes I was thinking of were already in 1.8.4.
How can we reproduce it : Instal a Dual-stack cluster using master with kubeadm (or kind ) I was unable to reproduce this issue in a kind dual stack cluster.

After upgrading coredns to 1.8.6 (from 1.8.0 installed by kind), and adding list/watch permission for endpointslice, the pods were ready. edit: It also works for coredns 1.8.4 - I'm unclear as to which version I should be checking.
let me check if is a regression in kind :thinking:
working with 1.8.6 and yesterdays kubernetes podIPs
This is weird, I hit a similar issue in openshift, endpoints doesn't match the IP family of the kubernetes.default service apiserver service is single stack, at least until this KEP fixes it What I don't understand is why the order of the IPs in kind is different let me try to fix both things /assign
my fault, sorry for the noise :sweat_smile:
Change:
"k8s.io/klog/v2" schedulerserverconfig "k8s.io/kubernetes/cmd/kube-scheduler/app/config" "k8s.io/kubernetes/cmd/kube-scheduler/app/options" <del> "k8s.io/kubernetes/pkg/api/legacyscheme" </del> "k8s.io/kubernetes/pkg/scheduler" kubeschedulerconfig "k8s.io/kubernetes/pkg/scheduler/apis/config" "k8s.io/kubernetes/pkg/scheduler/framework/runtime"

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: Kube-Scheduler exposes metrics in a secure manner (TLS and authentication required) on port by default. If one does not authenticate itself, the error message displayed is: What you expected to happen: Kube-Scheduler should emit a clear and understandable error message if authentication fails. Kube-Controller-Manager does that the following way: How to reproduce it (as minimally and precisely as possible): up a Kubernetes Cluster to access the exposed metrics endpoint (https://metrics-server:/metrics) without authentication Anything else we need to know?: xref: Environment: Kubernetes version (use ): 1.18.6 Cloud provider or hardware configuration: Bare metal OS (e.g: ): Debian GNU/Linux 10 (buster) Kernel (e.g. ): 4.19.0-9-amd64 Install tools: Kubeadm (Kube-Scheduler )
/sig scheduling instrumentation
If ok, I can try this fix /assign
/assign
Change:
func GetMasterAndWorkerNodesOrDie(c clientset.Interface) (sets.String, *v1.NodeList) { nodes := &v1.NodeList{} masters := sets.NewString() <del> all, _ := c.CoreV1().Nodes().List(metav1.ListOptions{}) </del> <ins> all, err := c.CoreV1().Nodes().List(metav1.ListOptions{}) ExpectNoError(err) </ins> for _, n := range all.Items { if system.IsMasterNode(n.Name) { masters.Insert(n.Name)

Discussion:
It started happening on 2018-08-16: https://k8s- https://k8s- https://k8s- /assign /cc /sig scalability I see that before this happens kubelet was able to successfully print all nodes in ready state. Also in kube- I can't see any 'GET /api/v1/nodes' call around that time which suggests that this is rather problem with out test infrastructure or networking than issue with nodes really being not ready that time. I see that GetMasterAndWorkerNodesOrDie never dies and ignores an error returning empty array in case of call error:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /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:
func TestConvert(t *testing.T) { sinceSeconds := int64(123) <ins> tailLines := int64(0) </ins> sinceTime := metav1.Date(2000, 1, 1, 12, 34, 56, 0, time.UTC) tests := []struct {

Discussion:
How works: : prints all lines. : prints the last line. : prints no lines. (Usually used with to follow new logs) How works: : prints all lines. : prints the last line. : prints all lines. <-------------- Diffierent. The reason is that the is ignored when converting the parameters Confirmed with What is the expected behavior? /cc
I've also noticed that even if or some arbitrarily low number is specified, it tries to read the whole logfile into memory. If it's a big file it can crash the worker node.
Do you mean the docker implementation? If I read their code correctly, docker read the whole log before tail into memory once tail is specified, which may cause problem if tail is a very large number. So in our own implementation, I've avoided that. ;) However, where do you see the ?
Tail should be *int in the API, is it not? On Oct 21, 2016, at 6:01 PM, Lantao Liu wrote: How docker logs works: docker logs --tail=-1 CONTAINERID: prints all lines. docker logs --tail=1 CONTAINERID: prints the last line. docker logs --tail=0 CONTAINERID: prints no lines. (Usually used with -f to follow new logs) How kubectl logs works: kubectl logs --tail=-1 PODNAME: prints all lines. kubectl logs --tail=1 PODNAME: prints the last line. kubectl logs --tail=0 PODNAME: prints all lines. <-------------- Diffierent. The reason is that the tail=0 is ignored when converting the parameters . Confirmed with /cc — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .
Agree tail=0 no logs is intended behavior On Oct 21, 2016, at 6:01 PM, Lantao Liu wrote: How docker logs works: docker logs --tail=-1 CONTAINERID: prints all lines. docker logs --tail=1 CONTAINERID: prints the last line. docker logs --tail=0 CONTAINERID: prints no lines. (Usually used with -f to follow new logs) How kubectl logs works: kubectl logs --tail=-1 PODNAME: prints all lines.

kubectl logs --tail=1 PODNAME: prints the last line. kubectl logs --tail=0 PODNAME: prints all lines. <-------------- Diffierent. The reason is that the tail=0 is ignored when converting the parameters . Confirmed with /cc — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .
Yeah, tail is . But if , kubelet will see .
I think the linked to is the problem.
The obvious workaround is to instead use: kubectl logs --tail=1
/sig cli
The line pasted by chao implies omitempty should not be false for tail.
I hate to bump, but 'bump'. Still an issue here. Can confirm works but does not.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale This is still relevant.
Any good news?
Change:
"csi_drivers_store_test.go", "csi_mounter_test.go", "csi_plugin_test.go", <ins> "csi_test.go", </ins> "csi_util_test.go", "expander_test.go", ],

Discussion:
Inline CSI volumes that are embedded in Pod specs still trigger all volume operation stages (attach, device mount, mount). Similar to plugin.CanAttach, a new plugin-wide method should be able to turn device mount off when the source is ephemeral volume. References See volume mount operation : This issue will use code from
/sig storage /assign
This will use work from
Change:
} } <del> // Validate PVC/PV binding </del> <ins> t.Log("Validating PVC/PV binding") </ins> for _, pvc := range test.boundPvcs { validatePVCPhase(t, config.client, pvc.name, config.ns, v1.ClaimBound, false) }

Discussion:
Which jobs are failing: pull-kubernetes-integration Which test(s) are failing: TestVolumeProvision Example: Since when has it been failing: Not sure, and aren't displaying any results /sig storage
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/assign /remove-lifecycle rotten Still seeing this, although not very frequently. Could indicate a race.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
latest failures:
take as an example the test fails b/c is set to PVC , which is not expected. our volume binder tries to dynamically provision it:
as for the test fails for the same reason when the scheduler volume binder tries to find volumes for PVC , its corresponding volume is not synced to volume binder or synced version is not in Available state so the volume binder will try to dynamically provision it too
I think the root cause is that the scheduler fails to find matching PVs in PV Assume Cache for the PVC because the PV in the Assume Cache is not in Available state or does not exist due to event delay. We should wait for the PV/PVC Assume Cache to be up to date before scheduling the pod.

However, it's not possible in integration tests. I think we can wait for the PV to be available or bound. This should reduce failures.
Change:
```console $ kubectl describe limits mylimits --namespace=limit-example Name:   mylimits <del> Type      Resource  Min  Max Default ----      --------  ---  --- --- Pod       memory    6Mi  1Gi - Pod       cpu       250m   2 - Container memory    6Mi  1Gi 100Mi Container cpu       250m   2 250m </del> <ins> Namespace:  limit-example Type        Resource      Min      Max      Request      Limit      Limit/Request ----        --------      ---      ---      -------      -----      ------------- Pod         cpu           200m     2        -            -          - Pod         memory        6Mi      1Gi      -            -          - Container   cpu           100m     2        200m         300m       - Container   memory        3Mi      1Gi      100Mi        200Mi      - </ins> ``` In this scenario, we have said the following: <del> 1. The total memory usage of a pod across all of its container must fall between 6Mi and 1Gi. 2. The total cpu usage of a pod across all of its containers must fall between 250m and 2 cores. 3. A container in a pod may consume between 6Mi and 1Gi of memory.  If the container does not specify an explicit resource limit, each container in a pod will get 100Mi of memory. 4. A container in a pod may consume between 250m and 2 cores of cpu.  If the container does not specify an explicit resource limit, each container in a pod will get 250m of cpu. </del> <ins> 1. If a max constraint is specified for a resource (2 CPU and 1Gi memory in this case), then a limit must be specified for that resource across all containers. Failure to specify a limit will result in a validation error when attempting to create the pod. Note that a default value of limit is set by *default* in file `limits.yaml` (300m CPU and 200Mi memory). 2. If a min constraint is specified for a resource (100m CPU and 3Mi memory in this case), then a request must be specified for that resource across all containers. Failure to specify a request will result in a validation error when attempting to create the pod. Note that a default value of request is set by *defaultRequest* in file `limits.yaml` (200m CPU and 100Mi memory). 3. For any pod, the sum of all containers memory requests must be >= 6Mi and the sum of all containers memory limits must be <= 1Gi; the sum of all containers CPU requests must be >= 200m and the sum of all containers CPU limits must be <= 2. </ins> Step 3: Enforcing limits at point of creation -----------------------------------------

Discussion:
Since resource QoS is implemented, limitrange also supports request constraint, we can add an example for that.
cc