jiebi/CodeConvo huggingface dataset:
Change:
assert.Nil(t, err) checkNumberOfEvents(t, 1, len(receivedEvents)) <del> ensureProperEventReturned(t, fakeEvent, receivedEvents[0]) </del> <ins> ensureProperEventReturned(t, fakeEvent2, receivedEvents[0]) </ins> } func TestGetEventsForNoTypeRequested(t *testing.T) {

Discussion:
I have some reports of a Node reporting a a resource capacity for cpu as a negative value. Any idea why cpu could report as a negative value? Is this an expected normal outcome? In its current state, it prevents any pods from being scheduled to that Node. Tips on how to debug further are appreciated. - any ideas?
Can you check machineInfo on Cadvisor or kubelet on the node?
a.k.a:
It is a bug in cAdvisor side. I am assigning it to you :-)
here is contents of /proc/cpuinfo Pertinent pieces of a log:
Machine is AWS instance if that matters....
We build the topology from system/cpu info. I think we can return partial topology information and ignore caches if its not present. This isn't a recent change though. Is it happening on just a single machine? I'll file a cAdvisor issue.
Can you link the referenced issue once created?
Re-assigning to since he's working on google/cadvisor
Could be this was caused by getting a Node on EC2 with old hypervisor, and I am the first victim...
That sounds likely. Most of the cache information is there in /proc/cpuinfo. So looks like the sysfs bits are disabled.
Can you try this cadvisor image on your machine and check /api/v1.3/machine output: sudo docker run  --volume=/:/rootfs:ro  --volume=/var/run:/var/run:rw  --volume=/sys:/sys:ro  --volume=/var/lib/docker/:/var/lib/docker:ro  --publish=8080:8080  --detach=true  --name=cadvisor  jnagal/cadvisor:canary
hmm
ah, selinux :( You'll need to run it with --privileged, I think. who's been dealing with it.
No luck with --privileged either on this box...
This has to do with SELinux, I think we had to disable it for this to work (some of our mounts are being denied). We're working on a better solution... This is not a problem in Kubernetes since we don't run Kubelet/cAdvisor in a Docker container.
ok, unfortunately, i have managed to kill docker on the box in question, and i cannot get the daemon to restart right now so I am not sure when that box will be available to debug against again.

I can provide an environment with a similar issue if required.
The fix is checked in to head. Can you build the binary and try?
Change:
const ( // https://docs.docker.com/engine/reference/api/docker_remote_api/ <del> // docker version should be at least 1.11.x MinimumDockerAPIVersion = "1.23.0" </del> <ins> // docker version should be at least 1.13.1 MinimumDockerAPIVersion = "1.26.0" </ins> // Status of a container returned by ListContainers. StatusRunningPrefix = "Up"

Discussion:
The current node e2e tests include images using Docker 1.11.x to , with the pending PR to test 18.06 () We should update the images to drop older docker versions. I think we can start by getting rid of 1.11 and 1.12, so that we still have three minor versions tested: , , and 1.13.x /cc (for cos and ubuntu)
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
/assign Yang, could you take a look? Thanks
Change:
return err } <del> type sortableGroupResource []groupResource </del> <ins> type sortableResource struct { resources []groupResource sortBy    string } </ins> <del> func (s sortableGroupResource) Len() int      { return len(s) } func (s sortableGroupResource) Swap(i, j int) { s[i], s[j] = s[j], s[i] } func (s sortableGroupResource) Less(i, j int) bool { ret := strings.Compare(s[i].APIGroup, s[j].APIGroup) </del> <ins> func (s sortableResource) Len() int { return len(s.resources) } func (s sortableResource) Swap(i, j int) { s.resources[i], s.resources[j] = s.resources[j], s.resources[i] } func (s sortableResource) Less(i, j int) bool { ret := strings.Compare(s.compareValues(i, j)) </ins> if ret > 0 { return false } else if ret == 0 { <del> return strings.Compare(s[i].APIResource.Name, s[j].APIResource.Name) < 0 </del> <ins> return strings.Compare(s.resources[i].APIResource.Name, s.resources[j].APIResource.Name) < 0 </ins> } return true } <ins> func (s sortableResource) compareValues(i, j int) (string, string) { switch s.sortBy { case "name": return s.resources[i].APIResource.Name, s.resources[j].APIResource.Name case "kind": return s.resources[i].APIResource.Kind, s.resources[j].APIResource.Kind } return s.resources[i].APIGroup, s.resources[j].APIGroup } </ins>

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add a sort parameter (or similar concept) to the command. Why is this needed: With the numerous amount of API resources (not counting custom ones), it is sometimes difficult locating them in the output. By default, API resources are not sorted by the name column (the first on the left) and often this is the column holding the information one wishes to query. A sort parameter would help more easily identify the object to be understood.
/sig usability
Change:
set -o nounset set -o pipefail <ins> USER_ID=$(id -u) GROUP_ID=$(id -g) </ins> DOCKER_OPTS=${DOCKER_OPTS:-""} DOCKER=(docker ${DOCKER_OPTS}) DOCKER_HOST=${DOCKER_HOST:-""}

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one):BUG REPORT Kubernetes version (use ):Client Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.2850+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-01-06T09:06:04Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.2753+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2017-01-04T08:46:56Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} What happened: How to reproduce it (as minimally and precisely as possible): the owner of file is not right
Do you need to be building as root?
I get an annoying message when building as normal user: So I run as root. There will return a error if the outpt build directory is not owned by root when running as root. I think we could use to fix it.
I hope to get some of your suggestions
did you previously build as ? you might need to before a build as a normal user works again.
Change:
func mergePluginSet(defaultPluginSet, customPluginSet v1beta2.PluginSet) v1beta2.PluginSet { disabledPlugins := sets.NewString() enabledCustomPlugins := make(map[string]pluginIndex) <ins> // replacedPluginIndex is a set of index of plugins, which have replaced the default plugins. replacedPluginIndex := sets.NewInt() </ins> for _, disabledPlugin := range customPluginSet.Disabled { disabledPlugins.Insert(disabledPlugin.Name) }

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 --Recent commit: import an issue when multiple custom plugin configured in scheduler config file, and those plugins are default plugins too. It was manipulating slice with index, but the slice is updated while index is not, which will cause the index out of range, see the exceptions listed below, config file should be handled properly without such exception override multiple default plugin in scheduler's config file. Kubernetes version (use ): latest (1.22) Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /assign
/sig scheduling /triage accepted
Change:
}}, } pleg.relist() <del> // event channel is full, discard events expected = []*PodLifecycleEvent{ </del> <ins> allEvents := []*PodLifecycleEvent{ </ins> {ID: "1234", Type: ContainerRemoved, Data: "c1"}, {ID: "1234", Type: ContainerDied, Data: "c2"}, {ID: "1234", Type: ContainerStarted, Data: "c3"}, {ID: "4567", Type: ContainerRemoved, Data: "c1"}, <ins> {ID: "4567", Type: ContainerStarted, Data: "c4"}, </ins> } <ins> // event channel is full, discard events </ins> actual = getEventsFromChannel(ch) <del> verifyEvents(t, expected, actual) </del> <ins> assert.True(t, len(actual) == 4, "channel length should be 4") assert.Subsetf(t, allEvents, actual, "actual events should in all events") </ins> } func TestDetectingContainerDeaths(t *testing.T) {

Discussion:
Repro:
/assign
GitHub didn't allow me to assign the following users: changyaowei. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <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
this test case was introduced by . Could you verify it ? cc
I believe this is fixed by - which is waiting on a merge. I'll re-ping the assigned reviewer :)
I already fixed it in , it waiting to be merged.
Change:
if err != nil { return false, err } <del> existingListeners = append(existingListeners, listenerList...) </del> <ins> for _, l := range listenerList { for _, lb := range l.Loadbalancers { if lb.ID == id { existingListeners = append(existingListeners, l) break } } } </ins> return true, nil })

Discussion:
Kubernetes version: $ kubectl version Client Version: version.Info{Major:"1", Minor:"3+", GitVersion:"v1.3.8-hpe.1", GitCommit:"", GitTreeState:"clean", BuildDate:"2016-09-22T23:27:29Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"3+", GitVersion:"v1.3.8-hpe.1.3+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2016-09-29T14:43:35Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: OpenStack Liberty, Neutron LBaaS V2 using Octavia OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A What happened: Deleting a LoadBalancer service results in the deletion of all LoadBalancer service's LBaaS Pools and Monitors. What you expected to happen: The Pools and Monitors for unrelated services should not be deleted How to reproduce it (as minimally and precisely as possible): 2 services with type=LoadBalancer for LBaaS resources to be created 1 of the 2 services created earlier output, all pools will have been deleted. Anything else do we need to know: Neutron's API ignores unknown paramaters. When listing pools etc, K8 attempts to filter on "LoadBalancerID", which is not a valid filter. As such, it is ignored by Neutron, and a list of all pools is returned. K8 then proceeds to delete each of the pools.
We're still experiencing this problem, or at least one with very similar symptoms -- having launched services of type LoadBalancer and then deleting one of them, it deletes all of the pools of all services. As the original report, we're also using OpenStack Liberty, Neutron LBaaS V2, and just updated to K8s 1.5.1 (from 1.4.5) hoping that this fixed our issue, but we are still experiencing the same problem after the upgrade.

Is there any other way in which we can help to debug the issue, without delving into the code? (On a side note, the commit which is supposed to fix this is included as part of the 1.5.0 release, so I am not sure if this issue has not been closed for some reason).
it is possible I missed a case in the original fix, the simplest test I found for this issue we had was to create 2x services with type=loadbalancer, wait for all the LBaaS resources to be provisioned, then delete one of the services and ensure the other's resources are still present. If this is failing, either these been a regression, or something else has gone horribly wrong :)
Hi thanks for coming back to this issue. Apparently not all cases deleting the LoadBalancers in OpenStack/liberty were doing the extra step of filtering. We were working on a fix, and submitted a pull request, which is being considered right now:
has merged. closing this issue /close
Change:
var endpointColumns = []string{"NAME", "ENDPOINTS", "AGE"} var nodeColumns = []string{"NAME", "STATUS", "AGE"} var daemonSetColumns = []string{"NAME", "DESIRED", "CURRENT", "NODE-SELECTOR", "AGE"} <del> var eventColumns = []string{"FIRSTSEEN", "LASTSEEN", "COUNT", "NAME", "KIND", "SUBOBJECT", "TYPE", "REASON", "SOURCE", "MESSAGE"} </del> <ins> var eventColumns = []string{"LASTSEEN", "FIRSTSEEN", "COUNT", "NAME", "KIND", "SUBOBJECT", "TYPE", "REASON", "SOURCE", "MESSAGE"} </ins> var limitRangeColumns = []string{"NAME", "AGE"} var resourceQuotaColumns = []string{"NAME", "AGE"} var namespaceColumns = []string{"NAME", "STATUS", "AGE"}

Discussion:
Hello Kubernetes, The order of the columns when you get events confused me. I was thinking, Turns out it's just a visual problem where these events are sorted correctly (by ), but the first column is . I think the first column should be because that's the order the events are listed.
This also confused me when I first saw it - I think this ordering would be more intuitive and help users discover the aggregation feature logically, instead of first having to grapple with why events are "out of order"
Should the order be always LASTSEEN,FIRSTSEEN or just when using -w? I have an ugly PR for the latter, but perhaps we should just go for the former.
Change:
return retval, nil }, WatchFunc: func(options metav1.ListOptions) (watch.Interface, error) { <del> w := watch.NewFake() </del> <ins> w := watch.NewRaceFreeFake() </ins> if options.ResourceVersion == "1" { go func() { // Close with a "Gone" error when trying to start a watch from the first list

Discussion:
In , when timeout or other error occurs, is called. This will make current routine terminated and miss the , which will lead to some leak routines. For example, this routine will block at waiting for No leak make any of these errors happen No response <details</details<details</details<details</details<details</details<details</details<details</details
sig Testing
I would like to take this up!
Actually, I have a fix in , but its fine if you have a better solution.
/sig api-machinery
/assign /triage accepted
Change:
if sysruntime.GOOS == "linux" { // AppArmor is a Linux kernel security module and it does not support other operating systems. klet.appArmorValidator = apparmor.NewValidator() <del> klet.softAdmitHandlers.AddPodAdmitHandler(lifecycle.NewAppArmorAdmitHandler(klet.appArmorValidator)) </del> <ins> klet.admitHandlers.AddPodAdmitHandler(lifecycle.NewAppArmorAdmitHandler(klet.appArmorValidator)) </ins> } leaseDuration := time.Duration(kubeCfg.NodeLeaseDurationSeconds) * time.Second

Discussion:
Kubelet soft admission handlers were created as a way for the Kubelet to block pods that cannot be run for reasons that can be resolved. In practice, this mechanism was only ever used by AppArmor (). Problems with soft-admission rejection: is only used by AppArmor, and only for situations that cannot realistically be resolved (host or build does not support apparmor) held in the blocked state must be manually cleaned up. While there they hold reserved capacity from the scheduler and continually retry syncpod. other features work this way - usually Kubelet hard rejects pods that it knows it cannot run, or the runtime fails to start the pod/container. This was originally to prevent controllers from continuously recreating pods that cannot run, but that is a separate problem that should be approached globally, rather than with this 1-off AppArmor solution. I propose we remove Kubelet soft admission entirely, and move the AppArmor admission handler to the hard-admission list. /sig node /milestone v1.31 /kind bug
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
We have a different, alpha mechanism: . We could change AppArmor, seccomp and other mechanisms to work either with PodSchedulingContext or its eventual replacement. IMO we only need to sketch out an approach and see that it looks viable; we don't have to block graduation for AppArmor support on a fleshed-out design.
From my admittedly limited PoV I'm not against removing soft admission, and I got no opinions about AppArmor specifically. However this seems to connected to the recent conversation we're having in WG serving and SIG-node about retriable vs unretriable errors so I think we would need some coordination cc
+1
My understanding is that after this PR: soft admission just doesn't make sense any longer.
Hello ! Just a reminder, the code freeze is starting (about from now), and while there is still plenty of time, we want to ensure that each PR has a chance to be merged on time.

As the issue is tagged for , is it still planned for this release?
Discussed in sig-node, decided to move forward with this (move AppArmor admission to the hard admission set, remove soft-admission code)
/assign
- do you want me to incorporate this change into
Change:
}), "Memory": ptrMatchAllFields(gstruct.Fields{ "Time":            recent(maxStatsAge), <del> "AvailableBytes":  bounded(100*framework.Mb, 100*framework.Gb), "UsageBytes":      bounded(10*framework.Mb, 10*framework.Gb), "WorkingSetBytes": bounded(10*framework.Mb, 10*framework.Gb), </del> <ins> "AvailableBytes":  bounded(100*framework.Mb, memoryLimit), "UsageBytes":      bounded(10*framework.Mb, memoryLimit), "WorkingSetBytes": bounded(10*framework.Mb, memoryLimit), </ins> // this now returns /sys/fs/cgroup/memory.stat total_rss <del> "RSSBytes":        bounded(1*framework.Kb, 1*framework.Gb), </del> <ins> "RSSBytes":        bounded(1*framework.Kb, memoryLimit), </ins> "PageFaults":      bounded(1000, 1E9), "MajorPageFaults": bounded(0, 100000), }),

Discussion:
/kind bug What happened: e2e node summary test fails on machines with more than 10Gb of ram. What you expected to happen: memory limit bounds to look at node capacity rather than hardcode an upper bound. How to reproduce it (as minimally and precisely as possible): have more ram on a box and run e2e-node FOCUS=Summary 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:
/sig node
Change:
"//cmd/kubeadm/app/constants:go_default_library", "//cmd/kubeadm/app/util/config:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", <del> "//staging/src/k8s.io/apimachinery/pkg/api/errors:go_default_library", </del> "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", "//staging/src/k8s.io/client-go/kubernetes/fake:go_default_library", <del> "//staging/src/k8s.io/client-go/testing:go_default_library", </del> ], )

Discussion:
What happened: Running fails consistently with timeout errors What you expected to happen: Unit tests should complete without any errors. If this was a configuration problem (e.g. unsupported go version), then I should see a meaningful error rather than just a timeout error. How to reproduce it (as minimally and precisely as possible): Run Anything else we need to know?: This issue has been present in my system for months. Environment: Kubernetes version (use ): master Cloud provider or hardware configuration: OS (e.g: ): Ubuntu 20.04 LTS (Focal Fossa) Kernel (e.g. ): Linux desktop 5.4.0-37-generic -Ubuntu SMP Wed Jun 3 18:57:02 UTC 2020 x8664 x8664 x86_64 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Others: go version go1.13.12 linux/amd64 (snap)
/sig testing
/assign
Issues targeted at the specific problematic packages and responsible SIGs will be more effective in getting this addressed
/remove-sig testing Unless we expect some broad testing change (like reconfiguring go test) this isn't SIG testing. This is SIG storage, node, and cluster lifecycle
/sig node /sig cluster-lifecycle /sig storage tagged the right sigs, though per-package issues are far more likely to drive getting this fixed
fix for cmd/kubeadm/app/phases/uploadconfig:
I'm going to open two more issues for the other two packages and work on them
sounds good, in that case please close this one.
New issues for reconciler and csi packages: ,
Closing. This problem has come up in the past, the solution is to just increase the timeout. I missed this the first time I read the doc.
Change:
return &nodeCopy, nil } } <del> return nil, nil </del> <ins> return nil, apierrors.NewNotFound(schema.GroupResource{Resource: "nodes"}, name) </ins> } func (m *FakeNodeHandler) runAsyncCalls() {

Discussion:
pkg/controller in I transformed that testcase into a fuzz driver and tested it with ]() It crash with "invalid memory address or nil pointer dereference" when some argument related data are fuzzed. Always No response No response Simplified PoC code is here: and it crashed as: /sig
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
/kind cleanup /sig node /priority backlog This nil pointer is never reported by end users which means that before we call AddOrUpdateTaintOnNode, the node existence is checked. To make the code more stable, fixing it is valid. This would avoid future bugs if somewhere calls AddOrUpdateTaintOnNode without checking whether the node exists. I opened for this. /remove-kind failing-test (which means falling test ci )
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]: