jiebi/CodeConvo huggingface dataset:
Change:
allPods := getPodsByLabels(c, ns, map[string]string{"name": labelName}) scheduledPods, notScheduledPods := e2epod.GetPodsScheduled(masterNodes, allPods) <del> printed := false printOnce := func(msg string) string { if !printed { printed = true return msg } return "" } framework.ExpectEqual(len(notScheduledPods), expectedNotScheduled, printOnce(fmt.Sprintf("Not scheduled Pods: %#v", notScheduledPods))) framework.ExpectEqual(len(scheduledPods), expectedScheduled, printOnce(fmt.Sprintf("Scheduled Pods: %#v", scheduledPods))) </del> <ins> framework.ExpectEqual(len(notScheduledPods), expectedNotScheduled, fmt.Sprintf("Not scheduled Pods: %#v", notScheduledPods)) framework.ExpectEqual(len(scheduledPods), expectedScheduled, fmt.Sprintf("Scheduled Pods: %#v", scheduledPods)) </ins> } func getPodsByLabels(c clientset.Interface, ns string, labelsMap map[string]string) *v1.PodList {

Discussion:
What happened: When an issue happens at the following check in the conformance test "validates resource limits of pods that are allowed to run": the debugging message ("Scheduled Pods: %#v") doesn't appear in the log at all like the following: ` and that makes debugging difficult actually. What you expected to happen: The debugging message should appear in the log if an issue happens. Environment: Kubernetes version (use ): v1.15.1 Cloud provider or hardware configuration: OpenStack OS (e.g: ): Ubuntu 18.04.1 LTS Kernel (e.g. ): 4.15.0-55-generic Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others:
/sig testing /sig scheduling
Change:
}, { kubernetesVersion: "1.10.0", <del> expectedVersion:   version.MustParseSemantic("3.1.11"), </del> <ins> expectedVersion:   version.MustParseSemantic("3.1.10"), </ins> expectedError:     nil, }, {

Discussion:
uses non existing etcd version for k8s 1.10.0. /kind bug /sig cluster-lifecycle
Change:
Containers: []v1.Container{ { Image: busyboxImage, <del> Name:  podName, </del> <ins> SecurityContext: &v1.SecurityContext{ SELinuxOptions: &v1.SELinuxOptions{ Type: "container_logreader_t", }, }, Name: podName, </ins> // If we find expected log file and contains right content, exit 0 // else, keep checking until test timeout Command: []string{"sh", "-c", "while true; do if [ -e " + expectedLogPath + " ] && grep -q " + log + " " + expectedLogPath + "; then exit 0; fi; sleep 1; done"},

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-crio-cgroupv1-node-e2e-conformance ContainerLogPath It was failing last week, then I disabled the SELinux while we investigated the issue Once this PR merges, I will enable the SELinux again for CRIO jobs. Once the SELinux is turned on and all the required components in the OS (e.g. crio, runc) are compiled with SELinux support we observed following errors in audit logs, Which points towards incorrect SELinux labeling.
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 node
Change:
if found { data, err := ioutil.ReadFile(path) if err != nil { <del> glog.Errorf("Error on reading termination-log %s: %v", path, err) </del> <ins> result.status.State.Terminated.Message = fmt.Sprintf("Error on reading termination-log %s: %v", path, err) </ins> } else { result.status.State.Terminated.Message = string(data) }

Discussion:
Error on reading termination-log /var/lib/kubelet/pods/-f986-11e4-9c82-/containers/skydns/933ddf81dbaf586e425240432429aa57bec939383e19bfb25d35d478597203f7: open /var/lib/kubelet/pods/-f986-11e4-9c82-/containers/skydns/933ddf81dbaf586e425240432429aa57bec939383e19bfb25d35d478597203f7: no such file or directory
I think there is a regression lately breaking termination-log.
might be related to this issue.
Was this fixed by ?
No, I still observed such error logs once a while, but so far those errors are red herring, without any breakage. Haven't get down to look into the detail yet.
If a pod gets deleted from the apiserver, kubelet (more specifically, the SyncPods function) would stop the container, and remove the orphaned volumes and pod directories. In the meantime, the per-pod workers (goroutines) may not have terminated yet. Therefore, the workers could be inspecting the containers to generate the status, causing the errors. Note that this does not happen if containers terminated by themselves while the pod is not yet deleted. The error messages are harmless, since the pods have been deleted and no one would examine the termination logs anyway. However, the fact that is full of such errors is misleading and confusing to users. I think this would be solved by graceful termination...
Change:
maxStartAge = time.Hour * 24 * 365 // 1 year maxStatsAge = time.Minute ) <del> // fetch node so we can know proper node memory bounds for unconstrained cgroups </del> <ins> ginkgo.By("Fetching node so we can match against an appropriate memory limit") </ins> node := getLocalNode(f) memoryCapacity := node.Status.Capacity["memory"] memoryLimit := memoryCapacity.Value()

Discussion:
Which jobs are failing: ci-cri-containerd-node-e2e Which test(s) are failing: Summary API [NodeConformance] when querying /stats/summary should report resource usage through the stats api Since when has it been failing: 2020 10-12 09:04 PDT Since Testgrid link: Reason for failure: Capability set incorrectly. CAPNETRAW should be NETRAW. I1013 18:39:19.058] Oct 13 18:10:51.403: INFO: At 2020-10-13 18:09:34 +0000 UTC - event for stats-busybox-0: {kubelet tmp-node-e2e--cos-81--1210-0} Failed: Error: failed to create containerd task: OCI runtime create failed: starting container process caused: unknown capability "CAPCAPNET_RAW": unknown Anything else we need to know: I have no idea where this is documented. It's a best guess.
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
it's a node_e2e test so /sig node
Seems like there's some dispute on who is doing the correct thing.
I would like to have a try.
please see discussion in
Change:
value: 1024-4999 - name: net.ipv4.tcp_keepalive_time value: "7200" <ins> - name: net.ipv4.tcp_fin_timeout value: "60" - name: net.ipv4.tcp_keepalive_intvl value: "75" - name: net.ipv4.tcp_keepalive_probes value: "9" </ins>

Discussion:
Add the following to be safe sysctls: net.ipv4.tcpfintimeout net.ipv4.tcpkeepaliveintvl net.ipv4.tcpkeepaliveprobes These are related settings to net.ipv4.tcpkeepalivetime that was enabled in These are related ipv4 TCP settings for tuning network connections between a client and a pod.
/sig network
May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node.
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : May you help provide some tests to ensure that setting this sysctl can't affect any other pods or the node. /sig nodes 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 node
I adjusted it with the plugin.
Would this change apply at the node level or the pod level? I assumed it would be at the pod level, and should not affect any other pods--however Kubernetes does not natively have any limits on network connections that I am aware of--but only the pod with the changed net settings would be affected.
To verify that a sysctl has an effect on other pods, we need to verify that it's a namespace sysctl.
Here's a simple test Use net.ipv4.tcpfintimeout sysctl to create a container check if it set on the host =It is the default value on host run another container attach to the network namespace of the one where the sysctl is set =results in sysctl being set Verify in another container under a different network namespace that it is not set =It is the default value According to the test results, net.ipv4.tcpfintimeout is a namespaced sysctl
I likewise verified and , which are also namespaced sysctl, and I believe we can add them to the safe sysctl /assign
Probably need to wait for to finish before start working on it
/triage accepted
Change:
}) AfterEach(func() { <del> framework.RunKubectlOrDie("delete", "deployment", dName, nsFlag) </del> <ins> err := wait.Poll(framework.Poll, 2*time.Minute, func() (bool, error) { out, err := framework.RunKubectl("delete", "deployment", dName, nsFlag) if err != nil { if strings.Contains(err.Error(), "could not find default credentials") { err = nil } return false, fmt.Errorf("kubectl delete failed output: %s, err: %v", out, err) } return true, nil }) Expect(err).NotTo(HaveOccurred()) </ins> }) It("should create a deployment from an image [Conformance]", func() {

Discussion:
https://k8s- Failed: [] Kubectl client [] Kubectl run deployment should create a deployment from an image [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl run deployment should create a deployment from an image [Conformance] {Kubernetes e2e suite}
https://k8s- Failed: [] Kubectl client [] Kubectl run deployment should create a deployment from an image [Conformance] {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention...
[FLAKE-PING] This flaky-test issue would love to have more attention...
https://k8s- Failed: [] Kubectl client [] Kubectl run deployment should create a deployment from an image [Conformance] {Kubernetes e2e suite}
Change:
}}, expected: errors.New("kubernetes.io/foo is an invalid extended resource name"), }, <ins> { name: "invalid redeclared custom predicate", policy: api.Policy{ Predicates: []api.PredicatePolicy{ {Name: "customPredicate1", Argument: &api.PredicateArgument{ServiceAffinity: &api.ServiceAffinity{Labels: []string{"label1"}}}}, {Name: "customPredicate2", Argument: &api.PredicateArgument{ServiceAffinity: &api.ServiceAffinity{Labels: []string{"label2"}}}}, }, }, expected: errors.New("Predicate 'customPredicate2' redeclares custom predicate 'ServiceAffinity', from:'customPredicate1'"), }, { name: "invalid redeclared custom priority", policy: api.Policy{ Priorities: []api.PriorityPolicy{ {Name: "customPriority1", Weight: 1, Argument: &api.PriorityArgument{ServiceAntiAffinity: &api.ServiceAntiAffinity{Label: "label1"}}}, {Name: "customPriority2", Weight: 1, Argument: &api.PriorityArgument{ServiceAntiAffinity: &api.ServiceAntiAffinity{Label: "label2"}}}, }, }, expected: errors.New("Priority 'customPriority2' redeclares custom priority 'ServiceAntiAffinity', from:'customPriority1'"), }, </ins> } for _, test := range tests {

Discussion:
Currently custom predicate and priorities can be created through the . The problem is that a custom predicate/priority, like ServiceAffinity, can be multiple times in the Policy with different names, possibly with different arguments. This semantic (i.e., specifying multiple instances of the same custom predicate with different arguments) is only useful if different s were specified because in all cases of custom predicates/priorities the arguments are merge-able (for example, from multiple CheckServiceAffinity custom predicates can be merged into one set). In the world of framework plugins, we don't currently have a way to maintain those semantics. to run. The question here: do we really want to maintain the old semantics of custom predicates and priorities? in other words, do we need to change the ComponentConfig API to somehow allow specifying multiple instances of the same Plugin with different arguments/weights, or should we consider that this is not supported? I always lean towards simplifying things, so my suggestion is to not support that, but I would like to know if there are actual deployments that rely on this. /sig scheduling /cc
/cc
We discussed this in the sig meeting, and put the issue for discussion on the scheduler and kubernetes-dev mailing list, I believe this behavior is not intentional, and so we should add logic to fail the scheduler configuration when a policy includes more than one custom predicate/priority of the same type. /assign
/assign
any progress on this one?
I haven't made any progress on this yet, but it's on my priority now
In migrating custom predicates to filter plugins , I am gonna ignore the custom predicate name and use the default name.
Change:
It("each node by switching off the network interface and ensure they function upon switch on", func() { // switch the network interface off for a while to simulate a network outage // We sleep 10 seconds to give some time for ssh command to cleanly finish before network is down. <del> testReboot(f.Client, "nohup sh -c 'sleep 10 && sudo ifdown eth0 && sleep 120 && sudo ifup eth0' >/dev/null 2>&1 &") </del> <ins> testReboot(f.Client, "nohup sh -c 'sleep 10 && sudo ip link set eth0 down && sleep 120 && sudo ip link set eth0 up' >/dev/null 2>&1 &") </ins> }) It("each node by dropping all inbound packets for a while and ensure they function afterwards", func() {

Discussion:
GCI Test Failing: (kubernetes-e2e-gci-gce-reboot-release-1.4) ([] Reboot [Disruptive] [Feature:Reboot] each node by switching off the network interface and ensure they function upon switch on) https://k8s-
Hmm. it looks like Kubelet is not detecting that network interfaces are down and updating its NodeStatus.
and commands are not in GCI. Is there any other equivalent command that we can use across GCI and other distros
Hmm... This test is testing "switching off network interface" specifically. I just try it with and . It should have the same effect.
I manually tested it with the following command on a GCI node. I observed the node get marked to NotReady and marked back to Ready. It should be okay. Just the test needs to be fixed.
Sweet! Thanks Do you want to continue owning this issue to have the test fixed?
Change:
return devicePath, nil } <del> if err := os.MkdirAll(globalPDPath, 0750); err != nil { return devicePath, fmt.Errorf("fc: failed to mkdir %s, error", globalPDPath) } </del> err = b.mounter.FormatAndMount(devicePath, globalPDPath, b.fsType, nil) if err != nil { return devicePath, fmt.Errorf("fc: failed to mount fc volume %s [%s] to %s, error %v", devicePath, b.fsType, globalPDPath, err)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Pod creation doesn't finish due to the following error. If the directory doesn't exist it will be created instead of returning error. What you expected to happen: Pod with FC volume works properly. How to reproduce it (as minimally and precisely as possible): Clean up under the "/var/lib/kubelet/plugins" Create a Pod with FC volume Environment: Kubernetes version (use ):Install tools: local-up- /cc
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig storage
Change:
func DeleteCollection(r rest.CollectionDeleter, checkBody bool, scope RequestScope, admit admission.Interface) http.HandlerFunc { return func(w http.ResponseWriter, req *http.Request) { if isDryRun(req.URL) && !utilfeature.DefaultFeatureGate.Enabled(features.DryRun) { <del> scope.err(errors.NewBadRequest("dryRun is not supported yet"), w, req) </del> <ins> scope.err(errors.NewBadRequest("the dryRun alpha feature is disabled"), w, req) </ins> return }

Discussion:
What happened: When a dry run request is made to a modifying endpoint, and the dry-run alpha feature is disabled, it returns the error message "dryRun is not supported yet" This was true in 1.11, but in 1.12, since the feature is in alpha now, the message should say something like "the dryRun alpha feature is disabled" /kind bug /sig api-machinery
Change:
prometheus.MustRegister(RuntimeOperations) prometheus.MustRegister(RuntimeOperationsLatency) prometheus.MustRegister(RuntimeOperationsErrors) <ins> prometheus.MustRegister(EvictionStatsAge) </ins> }) }

Discussion:
We should keep track of how stale stats used for evictions are. This will help track improvements in eviction latency, and help uncover regressions. cc If someone could assign this to me, I would appreciate that.
closing via
Change:
for _, pod := range m.activePods() { pstatus, ok := m.podStatusProvider.GetPodStatus(pod.UID) if !ok { <del> klog.InfoS("ReconcileState: skipping pod; status not found", "pod", klog.KObj(pod)) </del> <ins> klog.V(4).InfoS("ReconcileState: skipping pod; status not found", "pod", klog.KObj(pod)) </ins> failure = append(failure, reconciledContainer{pod.Name, "", ""}) continue }

Discussion:
kubernetes 1.19.2 seeing tons of these, feels like something that should be debug or info ... not really actionable or something that it should warn about ? /sig node
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
I am also seeing this same issue what's odd is that I cannot find the container it's looking for which is probably why its giving this message, so my question would be why is it looking for this container ID?
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-contributor-experience at . /lifecycle stale
/lifecycle frozen
I agree this should be lower than warning... /triage accepted /help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : I agree this should be lower than warning... /help 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
I think all InfoS messages under the should be moved to debug messages because it flood the log when the CPU manager enabled with the static policy.
/assign
Change:
t.Fatalf("Got error GETing: %v", err) } defer resp.Body.Close() <del> if resp.StatusCode != http.StatusInternalServerError { t.Errorf("expected status code %d, got %d", http.StatusInternalServerError, resp.StatusCode) </del> <ins> if resp.StatusCode != http.StatusOK { t.Errorf("expected status code %d, got %d", http.StatusOK, resp.StatusCode) </ins> } //Test with old docker version

Discussion:
We've run into issues like where the Kubelet was up but not healthy. The monit monitoring for Kubelet should ensure it is "healthy" rather than just alive. We need to define what healthy means in this context and monitor it based on that. An alternate option is for the Kubelet to exit when it gets into a situation it can't serve from. This may lead to crashloops so we'd need to be careful going this route. The answer is probably a bit of both.
Courtesy of healthchecking with monit:
Health check is under this umbrella issue:
Will send a PR shortly.
Change:
}, { in: &api.Pod{ <ins> Spec: api.PodSpec{SchedulerName: "scheduler1"}, }, fieldSelector: fields.ParseSelectorOrDie("spec.schedulerName=scheduler1"), expectMatch:   true, }, { in: &api.Pod{ Spec: api.PodSpec{SchedulerName: "scheduler1"}, }, fieldSelector: fields.ParseSelectorOrDie("spec.schedulerName=scheduler2"), expectMatch:   false, }, { in: &api.Pod{ </ins> Status: api.PodStatus{Phase: api.PodRunning}, }, fieldSelector: fields.ParseSelectorOrDie("status.phase=Running"),

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: When trying to list object using field spec.SchedulerName, we are getting the below error message. Failed to list : field label not supported: spec.schedulerName What you expected to happen: To be able to fetch pods using the list and watch based on the field 'spec.schedulerName' How to reproduce it (as minimally and precisely as possible): Create a simple controller to with a list and watch method. Set the FieldSelector ( in the ListOptions structure ) in the ListFunc and the WatchFunc to 'spec.SchedulerName=custome-SchedulerName' Running this controller yields the above error. Anything else we need to know?: Description: Unable to fetch pods based on the field 'spec.schedulerName'. This was in 1.6 version, for multi scheduler support in kubernetes. We need to be able to fetch pods 1) Assigned to a particular custom scheduler. 2) Should be able to fetch the state transition of the pods scheduled by a custom scheduler using the fields selector. Whats the correct way to use 'schedulerName' fields for fetching objects? Or is there any other way for the custom scheduler to determine the above information from the kubernetes? This is an urgent issue, any quick help/suggestion will be of great help. Environment: Kubernetes version : Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-06-29T23:15:59Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-07-14T01:48:01Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Install tools: kubeadm
There are no sig labels on this issue.

Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
/cc
cc
SIG API Machinery doesn't own the contents of the API--we only need to be involved if the mechanism needs to be general.
Given the error message mentioned in the bug report at the top of this thread, do you have a suggestion of what we forgot to do when we the SchedulerName field to the PodSpec? i.e. to enable field selection on the schedulerName field?
/cc me
Change:
return fmt.Errorf("unimplemented") } func (d *dummyStorage) Watch(_ context.Context, _ string, _ storage.ListOptions) (watch.Interface, error) { <del> return newDummyWatch(), nil </del> <ins> d.RLock() defer d.RUnlock() return newDummyWatch(), d.err </ins> } func (d *dummyStorage) Get(_ context.Context, _ string, _ storage.GetOptions, _ runtime.Object) error { <ins> d.RLock() defer d.RUnlock() </ins> return d.err } func (d *dummyStorage) GetList(_ context.Context, _ string, _ storage.ListOptions, listObj runtime.Object) error { <ins> d.RLock() defer d.RUnlock() </ins> podList := listObj.(*example.PodList) podList.ListMeta = metav1.ListMeta{ResourceVersion: "100"} return d.err

Discussion:
As Jordan pointed out in: watchcache treats RV=0 and RV="" the same way, even though it's not what we document: This should be fixed. /kind bug /sig api-machinery /priority important-soon
/assign
/triage accepted