jiebi/CodeConvo huggingface dataset:
Change:
apiVersion: v1 kind: Service metadata: <del> name: coredns </del> <ins> name: kube-dns </ins> namespace: kube-system labels: <del> k8s-app: coredns </del> <ins> k8s-app: kube-dns </ins> kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile kubernetes.io/name: "CoreDNS" spec: selector: <del> k8s-app: coredns </del> <ins> k8s-app: kube-dns </ins> clusterIP: {{ pillar['dns_server'] }} ports: - name: dns

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: e2e test "gci-gce" is running in 2 versions: with kube-dns as DNS Service : https://k8s- with CoreDNS as DNS Service : https://k8s- In CoreDNS use case the test is failing What you expected to happen: This e2e tests should not depend on what DNS service is running as default in K8s. CoreDNS is currently BETA, will move to GA soon (after v1.10 though) See : How to reproduce it (as minimally and precisely as possible): look at logs of dashboard : https://k8s- go run -v --test --test_args='--[sig-autoscaling]sDNSshorizontalsautoscalings[DisabledForLargeClusters]skube-dns-autoscalersshouldsscaleskube-dnsspodssinsbothsnonfaultysandsfaultysscenarios$' Anything else we need to know?: Environment: Kubernetes version (use ): branch master Cloud provider or hardware configuration: GCE Install tools: deployment intra-test Others: see https://k8s-
/sig autoscaling
/unsig cli
Looks like the test is searching specifically for a deployment labeled "kube-dns". There are several references to "kube-dns" scattered around it, actually.
Right now the tool "dns-horizontal-autoscaller" seems dedicated for kube-dns. This tools is deployed as "add-on" when enabled by this ENV variable : I guess we should have the definition of another dns-horizontal-autoscaller, dedicated to coredns (unless we generate the yaml file). and the choice of deployment is based on the ENV variable . see
Currently, the translation of the deployment of "dns-horizontal-autoscaller" for CoreDNS is in progress by It is expected that the corresponding e2e test will work as is (as the artifacts are selected by labels, which are the same for CroeDNS and kube-dns).
Change:
pvc := createPVC("pvc-rwm", "5G", []api.PersistentVolumeAccessMode{api.ReadWriteMany}) <del> w, _ := testClient.PersistentVolumes().Watch(api.ListOptions{}) </del> <ins> w, err := testClient.PersistentVolumes().Watch(api.ListOptions{}) if err != nil { t.Errorf("Failed to watch PersistentVolumes: %v", err) } </ins> defer w.Stop() <del> _, _ = testClient.PersistentVolumes().Create(pv_rwm) _, _ = testClient.PersistentVolumes().Create(pv_rwo) </del> <ins> _, err = testClient.PersistentVolumes().Create(pv_rwm) if err != nil { t.Errorf("Failed to create PersistentVolume: %v", err) } _, err = testClient.PersistentVolumes().Create(pv_rwo) if err != nil { t.Errorf("Failed to create PersistentVolume: %v", err) } </ins> <del> _, _ = testClient.PersistentVolumeClaims(api.NamespaceDefault).Create(pvc) </del> <ins> _, err = testClient.PersistentVolumeClaims(api.NamespaceDefault).Create(pvc) if err != nil { t.Errorf("Failed to create PersistentVolumeClaim: %v", err) } </ins> // wait until the controller pairs the volume and claim waitForPersistentVolumePhase(w, api.VolumeBound)

Discussion:
PersistentVolume integration tests fail sometimes: There are some interesting reports in the log like: Thans for report.
It turns out that volume integration tests have no logs at all, was not checked and I don't really know what's going on there. adds error checks to help me find out what's wrong there. Still, I suspect there are some troubles with etcd, not related to the test itself.
This flake affects also TestPersistentVolumeMultiPVs:
Extended logging got merged just now, please post links to logs when it breaks again!
Marking as P1 as per
I have no real usable logs, but I think it could be fixed by , it hasn't flaked since it was merged. And I have (in merge queue) to further stabilize the tests.
Not blocking this on 1.3.
It hasn't flaked for almost a month, can we close this?
Closing this issue since previous fixes made the flake go away.
Change:
if _, err := fmt.Fprintf( w, "%st%st%dt%st%st%st%st%st%st%s", <del> FirstTimestamp, </del> LastTimestamp, <ins> FirstTimestamp, </ins> event.Count, event.InvolvedObject.Name, event.InvolvedObject.Kind,

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:
import ( "fmt" "os" <ins> "os/exec" "path" "runtime" </ins> "strings" "github.com/golang/glog"

Discussion:
The goal of this issue is to design a CephFS driver using FUSE client for Kubernetes.</brExisting Ceph kernel client has the following drawbacks:</br• Kernel client does not support client-enforced quotas. • Kernel CephFS doesn't support quota or capacity, capacity requested by PVC is not enforced or validated. • Kernel CephFS doesn't work with SELinux, setting SELinux label in Pod's security context will not work.
Just a detail. Since we will rely on ceph-fuse, we will need the ceph-fuse client to be available on all kubernetes nodes. We can add a parameter to allow the use of the kernel client as well. I would say better make the fuse client opt-in and keep the kernel one as the default option. The kernel client might support quotas in the future. Thanks
/sig storage
We are also inclined to use fuse instead of kernel client ,any progress on this issue?
I like to continue this job and prepare to send a PR to make kubernetes support cephfs fuse mounting.
/assign I think this task would be valuable. =)
waiting for the PR, do you have a plane to support s3 fuse ?
No, no plan for s3fs-fuse currently
also see and cc
Ceph-fuse support in the command to display the specified secret, it may take some time to support, because it involves LibFUSE(I will follow up this demand). On the other hand, ceph-fuse has stability, quota function, expansion, upgrade and other advantages. Although ceph-fuse only supports the secret file way, but if it can be pushed to the k8s community, there is a very meaningful thing.
Change:
} // All pvs and pvcs that we operated on are bound <del> klog.V(4).InfoS("All PVCs for pod are bound", "pod", klog.KObj(pod)) </del> <ins> klog.V(2).InfoS("All PVCs for pod are bound", "pod", klog.KObj(pod)) </ins> return true, nil }

Discussion:
This line reads as if the bound has already happened: But, if I read correctly, the bound happens immediately after: And there is even a wait for confirmation after: The log line to better describe the actual state and another log line at V(2) to confirm that the operation ended. No response all supported versions <details</details<details</details<details</details<details</details<details</details
/sig storage
cc
/triage accepted
Change:
visible at runtime in the container. release: v1.9 file: test/e2e/common/node/downwardapi.go <ins> - testname: Ephemeral Container, update ephemeral containers codename: '[sig-node] Ephemeral Containers [NodeConformance] should update the ephemeral containers in an existing pod [Conformance]' description: Adding an ephemeral container to pod.spec MUST result in the container running. There MUST now be only one ephermal container found. Updating the pod with another ephemeral container MUST succeed. There MUST now be two ephermal containers found. release: v1.28 file: test/e2e/common/node/ephemeral_containers.go </ins> - testname: Ephemeral Container Creation codename: '[sig-node] Ephemeral Containers [NodeConformance] will start an ephemeral container in an existing pod [Conformance]'

Discussion:
[x] test approval issue : [x] test pr : 18 May 2023 [x] two weeks soak end date : 01 June 2023 [x] test promotion pr : According to following APIsnoop query, there are still 2 PodEphemeralcontainers endpoints that are not tested for Conformance. Using a number of existing e2e test practices a new has been created to address these 2 endpoints. The e2e logs for this test are listed below. This query shows the following podephemeralcontainers endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 2 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted cc
/reopen
Reopened this issue. <detailsIn response to : /reopen 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:
maxResults = -1 } <del> // NOTE: Since we store the elments in descending timestamp order "start" will // be a higher index than "end". </del> var startIndex int if start.IsZero() { // None specified, start at the beginning.

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:
RuntimeCgroupsName:    s.RuntimeCgroups, SystemCgroupsName:     s.SystemCgroups, KubeletCgroupsName:    s.KubeletCgroups, <ins> KubeletOOMScoreAdj:    s.OOMScoreAdj, </ins> CgroupsPerQOS:         s.CgroupsPerQOS, CgroupRoot:            s.CgroupRoot, CgroupDriver:          s.CgroupDriver,

Discussion:
runs in a container. Talos sets OOM score to -450 for the kubelet container and passes in the kubelet config. End result is that OOM score adj is -999 though. should have configured OOM score . Source code analysis. First, OOM score is set correctly from the config (flags): But then, in container manager, OOM score is reset to -999 via the following: This function should skip action if the PID is not running on the host: But the function looks to be confusing: When kubelet runs in a container with PID namespace shared with the host, kubelet's PID namespace will be equal to PID 1 namespace. If kubelet runs in a container with unshared PID namespace, kubelet's PID is 1 and its PID namespace is identical to PID 1 namespace. So how this function can return ever? Moreover, function is always setting OOM score to a hardcoded constant -999 ignoring configuation (). No response <details, reproduced with 1.22. </details<details</details<details</details<details</details<details</details<details</details
/sig node
/triage accepted
/assign
I don't think this method needs to change... I have make a draft PR for the default value to use the flag if present, but I would like more time to add some testing. Maybe you can have a look: ?
Thanks, this PR looks good to me, as it's going to set the OOM score to the configured value. And in our case kubelet runs in a container (not on the host, with proper OOM score via OCI spec), so this code should be even skipped, not sure how this can be addressed.
neither do I...
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
Change:
Time metav1.Time `json:"time,omitempty" protobuf:"bytes,1,opt,name=time"` // String detailing the error encountered during Attach or Detach operation. <del> // This string maybe logged, so it should not contain sensitive </del> <ins> // This string may be logged, so it should not contain sensitive </ins> // information. // +optional Message string `json:"message,omitempty" protobuf:"bytes,2,opt,name=message"`

Discussion:
This came up as a follow up to Also rather than opening 5 different issues - we are going to use this github issue to track all follow up items mentioned here -
/sig storage
/assign /assign
: PR
and the rest is fixed in
Change:
filegroup( name = "all-srcs", <del> srcs = [":package-srcs"], </del> <ins> srcs = [ ":package-srcs", "//pkg/kubelet/kuberuntime/logs:all-srcs", ], </ins> tags = ["automanaged"], )

Discussion:
We should make the CRI log parsing code in kubelet to be a library. So that container runtimes and external tools don't need to copy the whole code ( vendor it instead ). Referring
/assign
/sig node
I can help on it.
/assign
GitHub didn't allow me to assign the following users: yanxuean. 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
Thanks. I have a branch ready for this. Will open a PR later and ping you when it is out.
ok
Change:
}, ID:         &ID, InstanceID: &instanceID, <del> Location:   &ss.Cloud.Location, </del> <ins> Location:   &ss.Location, </ins> } } virtualMachineScaleSetVMsClient.setFakeStore(ssVMs) <del> ss.Cloud.VirtualMachineScaleSetsClient = virtualMachineScaleSetsClient ss.Cloud.VirtualMachineScaleSetVMsClient = virtualMachineScaleSetVMsClient </del> <ins> ss.VirtualMachineScaleSetsClient = virtualMachineScaleSetsClient ss.VirtualMachineScaleSetVMsClient = virtualMachineScaleSetVMsClient </ins> } func TestGetScaleSetVMInstanceID(t *testing.T) {

Discussion:
/kind bug What happened: https://k8s-
/sig azure
I find the root cause, and can fix it.
/kind bug
/cc
Cool, thanks
Change:
var err error framework.AllNodesReady(cs, time.Minute) <del> masterNodes, nodeList, err = e2enode.GetMasterAndWorkerNodes(cs) </del> <ins> // NOTE: Here doesn't get nodeList for supporting a master nodes which can host workload pods. masterNodes, _, err = e2enode.GetMasterAndWorkerNodes(cs) </ins> if err != nil { e2elog.Logf("Unexpected error occurred: %v", err) } <ins> nodeList, err = e2enode.GetReadySchedulableNodesOrDie(cs) if err != nil { e2elog.Logf("Unexpected error occurred: %v", err) } </ins> // TODO: write a wrapper for ExpectNoErrorWithOffset() framework.ExpectNoErrorWithOffset(0, err)

Discussion:
What happened: The conformance test "validates resource limits of pods that are allowed to run" is failed if master node doesn't have taints. What you expected to happen: All conformance tests should pass even if a master node doesn't have taints. How to reproduce it (as minimally and precisely as possible): If a master node has taints like many cases, the test can pass like the following: However if the master node doesn't have any taints, the test cannot pass like: Anything else we need to know?: I am guessing this issue can be related to Environment: Kubernetes version (use ): v1.15.1 Cloud provider or hardware configuration: OpenStack OS (e.g: ): Ubuntu 18.04.2 LTS Kernel (e.g. ): 4.15.0-46-generic Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others:
/sig scheduling
The test log contains only, that means the test doesn't create a pod on the master node which doesn't have any taints when this issue happens. The following log is the part of when the issue happened. Important line is which says additional-pod which was expected to be failed to be schedule is assigned to the master node.
nodeList is gotten from as in BeforeEach() step. And as I said on the function is problematic now.
The discussion on the slack:
Change:
} w.fsWatcher = fsWatcher <ins> // Traverse plugin dir and add filesystem watchers before starting the plugin processing goroutine. if err := w.traversePluginDir(w.path); err != nil { w.Stop() return fmt.Errorf("failed to traverse plugin socket path %q, err: %v", w.path, err) } // Traverse deprecated plugin dir, if specified. if len(w.deprecatedPath) != 0 { if err := w.traversePluginDir(w.deprecatedPath); err != nil { w.Stop() return fmt.Errorf("failed to traverse deprecated plugin socket path %q, err: %v", w.deprecatedPath, err) } } </ins> w.wg.Add(1) go func(fsWatcher *fsnotify.Watcher) { defer w.wg.Done() for { select { case event := <-fsWatcher.Events: //TODO: Handle errors by taking corrective measures <del> w.wg.Add(1) func() { defer w.wg.Done() if event.Op&fsnotify.Create == fsnotify.Create { err := w.handleCreateEvent(event) if err != nil { klog.Errorf("error %v when handling create event: %s", err, event) } } else if event.Op&fsnotify.Remove == fsnotify.Remove { err := w.handleDeleteEvent(event) if err != nil { klog.Errorf("error %v when handling delete event: %s", err, event) } </del> <ins> if event.Op&fsnotify.Create == fsnotify.Create { err := w.handleCreateEvent(event) if err != nil { klog.Errorf("error %v when handling create event: %s", err, event) </ins> } <del> return }() </del> <ins> } else if event.Op&fsnotify.Remove == fsnotify.Remove { err := w.handleDeleteEvent(event) if err != nil { klog.Errorf("error %v when handling delete event: %s", err, event) } } </ins> continue case err := <-fsWatcher.Errors: if err != nil {

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:
"k8s.io/apimachinery/pkg/fields" "k8s.io/client-go/tools/cache" <del> "encoding/json" </del> appsv1 "k8s.io/api/apps/v1" <ins> autoscalingv1 "k8s.io/api/autoscaling/v1" //Added new </ins> v1 "k8s.io/api/core/v1" apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"

Discussion:
[x] two weeks soak end date : 26 Feb 2021 According to this APIsnoop query, there are still some remaining Deployment endpoints which are untested. with this query you can filter untested endpoints by their category and eligibility for conformance. e.g below shows a query to find all conformance eligible untested,stable,core endpoints Create a Deployment with a static label Read the Deployment Update the DeploymentScale Get the DeploymentScale to ensure it is updated Patch the DeploymentScale Read the DeploymentScale to ensure it is Patch Delete the Namespace and Deployment Due to the complexity of setting up the resources for APIService we have used the current e2e test as template. It has been extended in a for review. example endpoint | useragent ----------------------------------------|
patchAppsV1NamespacedDeploymentScale | (linux/amd64) kubernetes/$Format -- [sig-apps] Deployment Deployment should have a working scale subresource readAppsV1NamespacedDeploymentScale | (linux/amd64) kubernetes/$Format -- [sig-apps] Deployment Deployment should have a working scale subresource replaceAppsV1NamespacedDeploymentScale | (linux/amd64) kubernetes/$Format -- [sig-apps] Deployment Deployment should have a working scale subresource (3 rows) If a test with these calls gets merged, test coverage will go up by N points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
Issue was presented in the Conformance meeting of 9 Feb 2021 and it was agreed that that method see to achieve the purpose and a PR can be created. A similar approach would be taken for the DepoymentScale endpoints, and this issue was created for that purpose.
/reopen
Reopened this issue. <detailsIn response to : /reopen 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:
errCh := make(chan error, concurrency) ready := newReady() ready.set(false) <ins> wg := sync.WaitGroup{} wg.Add(2 * concurrency) </ins> for i := 0; i < concurrency; i++ { go func() { errCh <- ready.wait(context.Background()) }() go func() { <ins> defer wg.Done() </ins> ready.set(false) }() go func() { <ins> defer wg.Done() </ins> ready.set(true) }() } <ins> // Last one has to be set to true. wg.Wait() </ins> ready.set(true) for i := 0; i < concurrency; i++ { if err := <-errCh; err != nil { t.Errorf("unexpected error %v on channel %d", err, i)

Discussion:
a test that is flaking at a ~3% failure rate with : Originally posted by in /sig api-machinery /assign /cc /kind failing-test
/assign

all the failures I've seen weren't failures, but rather timeouts. I wasn't able to reproduce it either by running the test itself, but I know what the potential failure is here: the and goroutines are somehow finishing the last one that is called is 1+ of goroutine is starting after that In this case the last will never finish. The fix is in
not sure if it's related, but TestGetCurrentResourceVersionFromStorage in the same package started flaking at the same time: looks like the fix in won't address that one
that's a different thing for sure. - can you please take a look at it - it's a newly test from yesterday
Spinned of for the other issue mentioned by Jordan.