jiebi/CodeConvo huggingface dataset:
Code change:
// cleanupPodsInNamespace deletes the pods in the given namespace and waits for them to // be actually deleted. func cleanupPodsInNamespace(cs clientset.Interface, t *testing.T, ns string) { <del> if err := cs.CoreV1().Pods(ns).DeleteCollection(context.TODO(), *metav1.NewDeleteOptions(0), metav1.ListOptions{}); err != nil { </del> <ins> if err := cs.CoreV1().Pods(ns).DeleteCollection(context.TODO(), metav1.DeleteOptions{}, metav1.ListOptions{}); err != nil { </ins> t.Errorf("error while listing pod in namespace %v: %v", ns, err) return }

Related discussion:
text: <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Conformance - GCE - master (ci-kubernetes-gce-conformance-latest) Which test(s) are failing: [sig-scheduling] SchedulerPreemption [Serial] PreemptionExecutionPath runs ReplicaSets to verify preemption running path [Conformance]Changes Since when has it been failing: 2020-06-08 22:27 PDT Testgrid link: Reason for failure: Regression by Anything else we need to know: /sig scheduling /priority critical-urgent
cc/ /assign
Code change:
} // Walks through the plugin directory discover any existing plugin sockets. <ins> // Goroutines started here will be waited for in Stop() before cleaning up. // Ignore all errors except root dir not being walkable </ins> func (w *Watcher) traversePluginDir(dir string) error { return w.fs.Walk(dir, func(path string, info os.FileInfo, err error) error { if err != nil { <del> return fmt.Errorf("error accessing path: %s error: %v", path, err) </del> <ins> if path == dir { return fmt.Errorf("error accessing path: %s error: %v", path, err) } glog.Errorf("error accessing path: %s error: %v", path, err) return nil </ins> } switch mode := info.Mode(); {

Related discussion:
text: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: https://k8s- Which test(s) are failing: should unmount if pod is force deleted while kubelet is down [Disruptive][Slow] Since when has it been failing: 11/07/18 15:02 Testgrid link: https://k8s- Reason for failure: The test case stops and starts kubelet, and it seems like kubelet is unable to start again Anything else we need to know: <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test
cc
Thanks for opening this Looking at , looks like could be the cause? /assign can you please look into this as priority. This is failing critical release blocking tests. /cc /sig cli /priority critical-urgent /milestone v1.13
It looks like kubelet keeps restarting. The error right before restarting is:
/assign
This bug could have been exposed by the newly tests in
Hmm, so I see two errors: Which is a Fatal error and would prevent Kubelet from starting anyways. In which case this error is handled correctly by the pluginwatcher, but I'm not sure preventing Kubelet from starting is the desired behavior. Should we log this error and skip it? There also seem to be a cleanup issue here on that file is this expected? This one is clearly a bug and not really handled correctly. It's due to the fact that we encounter an error at start, cleanup but don't wait for the gorountines to finish before cleaning up. I can send in a fix pretty easily for the second issue, basically add a waitgroup in the . For the first error, what do we think is the expected behavior?
This was mentioned in as well. /cc
Is this related to the issue where plugin watcher is recursively scanning for sockets?
Also, it should be noted that the path it's erroring on is not a socket type.
That's a bit different, as it is intended to scan recursively. Also note that the error here is produced by . What should be our behavior in such a case? Ignore that error?
I'm not sure if we want to be recursively scanning. The volume directories are mount points, which means there could be lots of files/directories existing in those volumes.
Code change:
} // Walks through the plugin directory discover any existing plugin sockets. <ins> // Goroutines started here will be waited for in Stop() before cleaning up. // Ignore all errors except root dir not being walkable </ins> func (w *Watcher) traversePluginDir(dir string) error { return w.fs.Walk(dir, func(path string, info os.FileInfo, err error) error { if err != nil { <del> return fmt.Errorf("error accessing path: %s error: %v", path, err) </del> <ins> if path == dir { return fmt.Errorf("error accessing path: %s error: %v", path, err) } glog.Errorf("error accessing path: %s error: %v", path, err) return nil </ins> } switch mode := info.Mode(); {

Related discussion:
text: maybe we can put a limit on depth of plugin directory for on the same PR:
Ideally the directory that the plugin sockets are dropped in should be different from the directory where mounts happens. Currently the plugin socket directory is: ) The mounts directory is (so far so good). Problem is the "global mount" directory is also :( So options are: recursively scanning like suggested, and say plugins will can only be directly under This will break existing plugins, for example, the GCP plugin is at (see ). recursively scanning but change the plugin socket directory to ? This will also break existing plugins, like the GCP one pointed out above. the plugin dir the same, and leave recursion in, but put a limit on depth of plugin directory as suggested by This is ugly but may be the cleanest solution.
This conversation is completely different from the bug surfaced by this issue. Let's move that to the corresponding issue: I have a fix ready to go out for the panic, we should figure out what behavior we expect Kubelet to have when encountering this error from filepath.Walk: Should we ignore it?
Ignoring the error (with a warning maybe) instead of failing all of kubelet seems reasonable to me. If the plugin did not setup their registration socket correctly, then the end result should be that the plugin fails to register, but all other plugins should continue to work correctly.
the latest runs of this job no longer timesout - Instead I am seeing a new CSI related failure Is this expected. Do we want to track that failure in this bug now or do we have a separate issue?
the latest test logs indicate some test-infra issue:
the same shows up as a timeout on that particular test. Lets wait for the next run. but somehow the timeout seems to have gone. Are we still planning to merge and associated with this issue?
should be merged as it fixes a bug. can you help with approval? Thanks!
are you missing the right PR# in the comment above?
this is the correct PR -
/reopen Keeping it open until we can see the job pass a couple of rounds
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.
Code change:
} // Walks through the plugin directory discover any existing plugin sockets. <ins> // Goroutines started here will be waited for in Stop() before cleaning up. // Ignore all errors except root dir not being walkable </ins> func (w *Watcher) traversePluginDir(dir string) error { return w.fs.Walk(dir, func(path string, info os.FileInfo, err error) error { if err != nil { <del> return fmt.Errorf("error accessing path: %s error: %v", path, err) </del> <ins> if path == dir { return fmt.Errorf("error accessing path: %s error: %v", path, err) } glog.Errorf("error accessing path: %s error: %v", path, err) return nil </ins> } switch mode := info.Mode(); {

Related discussion:
text: </details
I see just one CSI test timing out in serial job Is that something the fixes here attempted to resolve? if not I can open a new issue if it persists and close this one out. Thanks.
The test mentioned in my comment above was a flake.. closing this issue now. will open a new issue for the flake
I'm getting the following related error on a busy Node: In the above case it's a full filesystem, but I imagine the same error would pop up with a RO filesystem as well. Looking at the patch, I'd expect kubelet would still be failing to start when it tries to watch it. (above was from a v1.12.3 cluster) , what do you reckon?
plugin watcher fixes for 1.12 are expected to be released with 1.12.5:
, I understand that I'm missing that patch. The patch code, however, would not make a difference in this case, if I read it correctly. It would not prevent the recursive dive into mounted volumes, as the errors happening at the deeper levels of that dive.
The patch blacklists the plugin watcher from searching the directory
OK, I was looking at the wrong patch after all (). Thanks for the clarifications.
Code change:
} return nil }, <ins> // MinionList.Items had a wrong name in v1beta1 func(in *MinionList, out *v1beta1.MinionList) error { Convert(&in.JSONBase, &out.JSONBase) Convert(&in.Items, &out.Items) out.Minions = out.Items return nil }, func(in *v1beta1.MinionList, out *MinionList) error { Convert(&in.JSONBase, &out.JSONBase) if len(in.Items) == 0 { Convert(&in.Minions, &out.Items) } else { Convert(&in.Items, &out.Items) } return nil }, </ins> ) }

Related discussion:
text: should have the JSON attribute name "items", not "minions"
Doh! Fix now and break clients?
Define Items and Minions and use Convertors to resolve it?
Sure. I'll make a fix.
Code change:
"k8s.io/kubernetes/pkg/kubelet/network" proberesults "k8s.io/kubernetes/pkg/kubelet/prober/results" kubetypes "k8s.io/kubernetes/pkg/kubelet/types" <del> "k8s.io/kubernetes/pkg/kubelet/util/cache" </del> "k8s.io/kubernetes/pkg/types" "k8s.io/kubernetes/pkg/util/flowcontrol" "k8s.io/kubernetes/pkg/util/oom"

Related discussion:
text: The recently merged PR a version cache in dockertools, which makes the test  flaky. The reason is that injected error into fakedockerclient and then expected to see the error from right after that (See ). However, the error was consumed by the goroutine which periodically updates the version cache (See ). The docker daemon version is rarely updated, and we only need version once for each container creating, during which we also do container create, start, inspect #etc. 1) Do we care about the cost of the call so much that we have to introduce the complexity? 2) Kubelet periodically calls , can we rely on that to update the cache? Anyhow, at least, we should disable the cache or have a fake one in the unit test. :) /cc
I once considered move this cache to runtime level, while thus may need to change runtime interface. What if only cache apiversion?
We can only get via , so there will still be the data race. :) One option is to update the version cache in , now kubelet periodically call to check the runtime status. Another better option is to cache the version in layer, now is under our control, we can refactor it with an additional argument indicating whether to use cached value or get directly from the daemon. If we cache the version only for performance, I prefer the second option which is cleaner and more efficient. :)
OK, will look into this tonight
The unit test itself should not start a goroutine to update the cache (unless you're actually testing the goroutine). We should disable it anyway, as we often do in our unit tests. It also sounds like we don't need a goroutine dedicated for this. If we can tolerate the additional overhead from time to time, we can set a expiration time (e.g., 1 minute), and only call the runtime if the entry expires.
Totally agree. :) Maybe a new function in wrapping the update logic, or wrapping the logic in the .
expiration time sounds good in this case
This is happening quite frequently - increasing priority to P0.
Code change:
// Sleep 1s to verify no detach are triggered after second pod is added in the future. time.Sleep(1000 * time.Millisecond) verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateAttached, asw) <del> verifyVolumeNoStatusUpdateNeeded(t, logger, generatedVolumeName, nodeName1, asw) </del> <ins> // verifyVolumeNoStatusUpdateNeeded(t, logger, generatedVolumeName, nodeName1, asw) </ins> // Add a third pod which tries to attach the volume to a different node. // At this point, volume is still attached to first node. There are no status update for both nodes.

Related discussion:
text: TestRunOneVolumeDetachFailNodeWithReadWriteOnce 4 times since 03-19 23:00 PDT, intermittently ! https://k8s- Still investigating whether this is a tolerable flake or not with more history than testgrid view, or otherwise would appreciate input from anyone with expertise in this test, especially as regards to whether this should be a blocker for tomorrows beta cut. maybe: /sig storage /sig testing
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
is already open for this, looks like it is attempting to fix it
thank you!!! closing this in favor of that one, which I also to our CI signal project board for visibility. For completeness: since it's a longer standing issue, well identified as a flake and not a failure and also actively in progress, NOT considering it a blocker for the go/nogo signal for the beta tomorrow. /close
Closing this issue. <detailsIn response to : thank you!!! closing this in favor of that one, which I also to our CI signal project board for visibility. For completeness: since it's a longer standing issue, well identified as a flake and not a failure and also actively in progress, NOT considering it a blocker for the go/nogo signal for the beta tomorrow. 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
Code change:
// Sleep 1s to verify no detach are triggered after second pod is added in the future. time.Sleep(1000 * time.Millisecond) verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateAttached, asw) <del> verifyVolumeNoStatusUpdateNeeded(t, logger, generatedVolumeName, nodeName1, asw) </del> <ins> // verifyVolumeNoStatusUpdateNeeded(t, logger, generatedVolumeName, nodeName1, asw) </ins> // Add a third pod which tries to attach the volume to a different node. // At this point, volume is still attached to first node. There are no status update for both nodes.

Related discussion:
text: pull-kubernetes-unit TestRunOneVolumeDetachFailNodeWithReadWriteOnce Jan 7th, 2022 Check volume <fake-plugin/volume-nameis reported as attached to node <fail-detach-node, got false, expected true No response_ /sig storage
/cc
this is the top unit test flake according to
cc
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]:
I think this test is no longer flaky by checking the test grid, close it now.
Unfortunately this does still seem to be flaky: Here was the output from : /reopen
Reopened this issue. <detailsIn response to : Unfortunately this does still seem to be flaky: 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
/remove-lifecycle stale
still the case
How about adding some logging to help troubleshoot this? I looked at it a little, but it is hard to tell which part of the test is failing. PR
/
This is still happening
/triage accepted
From the logs, in the OneVolumeDetachFailNodeWithReadWriteOnce test, succeeded, but the next verification failed. In verifyVolumeAttachedToNode, the attachState is from calling and within asw, it calls . In verifyVolumeReportedAsAttachedToNode, the volumes are obtained from calling , it seems that the node is not in asw.nodesToUpdateStatusFor at this step. Cannot reproduce locally. I tried to run the test 100 times locally with debug.Stack()... 3 * 100 times all passed.
Tried to run stress test on my linux machine as well but still cannot reproduce. Command: Result: Also tried running n process in parallel. Command: Result:
It seems like it happens more frequently.
Code change:
// Sleep 1s to verify no detach are triggered after second pod is added in the future. time.Sleep(1000 * time.Millisecond) verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateAttached, asw) <del> verifyVolumeNoStatusUpdateNeeded(t, logger, generatedVolumeName, nodeName1, asw) </del> <ins> // verifyVolumeNoStatusUpdateNeeded(t, logger, generatedVolumeName, nodeName1, asw) </ins> // Add a third pod which tries to attach the volume to a different node. // At this point, volume is still attached to first node. There are no status update for both nodes.

Related discussion:
text: But I may have no time to dig into the cause. Let's see.
cc as the test author.
The problem is that this test has a lot of dependency on the sleeps that are hardcoded with a very narrow scope, but our CI seems to be able to stress it much more. As soon as you slightly change one of the sleep duration it starts to flake locally The test can not make an assumption that timing is perfect, even more in the sub second range can someone in sig-storage review this test and make it less dependant on those tight sleeps?
According to most failures, it failed at Line 660. Let me run some stress locally. with 250ms sleep with 100ms sleep
I agree this test case is too brittle due to its specific timing dependencies. To fix this, I suggest reworking the test case to: 1) Add retry with timeout to wait for final conditions 2) Remove the intermediate timing-based state transition checks. Instead, we can keep track of state transitions in the Fakes and validate those stats. wdyt?
Friendly ping from 1.27 CI Signal that this test is still a noisy flake on the master-blocking dashboard as CI Signal has flagged it in and
Code change:
How To Run ------ <del> ``` cd kubernetes/test/integration/scheduler_perf </del> <ins> ```shell # In Kubernetes root path make generated_files cd test/integration/scheduler_perf </ins> ./test-performance.sh ```

Related discussion:
text: <!-- 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: Scheduler performance test does not work: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Run schedulerperf by following: 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:
/assign
/sig scheduling
Code change:
cniArch          = "amd64" cniDirectory     = "cni/bin" // The CNI tarball places binaries under directory under "cni/bin". cniConfDirectory = "cni/net.d" <del> cniURL           = "https://storage.googleapis.com/kubernetes-release/network-plugins/cni-plugins-" + cniArch + "-" + cniVersion + ".tgz" </del> <ins> cniURL           = "https://dl.k8s.io/network-plugins/cni-plugins-" + cniArch + "-" + cniVersion + ".tgz" </ins> ) const cniConfig = `{

Related discussion:
text: We have a new vanity url, , which redirects to the GCS release bucket - e.g. Right now, the https endpoint doesn't work, since isn't in the list of domains on the certificate. Once it works, we should switch all references over to the nicer vanity URL. x-ref
So what it required to make this issues actionable? Where to add this for the certificate?
the issue tracking that is
This needs to be triaged as a release-blocker or not for 1.5
not a release blocker.
Is it appropriate to move this to the next milestone or clear the 1.5 milestone? (and remove the non-release-blocker tag as well)
can this be closed?
I forgot to get to this in 1.6, but it'd still be good to do.
do you want this in v1.7? is there a sig to own this?
doesn't need to block 1.7, no.
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
/sig release
Code change:
func TestSyncReplicationControllerCreates(t *testing.T) { c := clientset.NewForConfigOrDie(&restclient.Config{Host: "", ContentConfig: restclient.ContentConfig{GroupVersion: &api.Registry.GroupOrDie(v1.GroupName).GroupVersion}}) <del> manager, _, rcInformer := newReplicationManagerFromClient(c, BurstReplicas) </del> <ins> manager, podInformer, rcInformer := newReplicationManagerFromClient(c, BurstReplicas) </ins> <del> // A controller with 2 replicas and no pods in the store, 2 creates expected </del> <ins> // A controller with 2 replicas and no active pods in the store. // Inactive pods should be ignored. 2 creates expected. </ins> rc := newReplicationController(2) rcInformer.Informer().GetIndexer().Add(rc) <ins> failedPod := newPod("failed-pod", rc, v1.PodFailed, nil, true) deletedPod := newPod("deleted-pod", rc, v1.PodRunning, nil, true) deletedPod.DeletionTimestamp = &metav1.Time{Time: time.Now()} podInformer.Informer().GetIndexer().Add(failedPod) podInformer.Informer().GetIndexer().Add(deletedPod) </ins> fakePodControl := controller.FakePodControl{} manager.podControl = &fakePodControl

Related discussion:
text: https://k8s- Failed: [] Network Partition [Disruptive] [Slow] [] [ReplicationController] should eagerly create replacement pod during network partition when termination grace is non-zero {Kubernetes e2e suite}
https://k8s- seems to be the first failure here. It seems to have gone in with a bunch of RC/RS changes () cc/
Code change:
} // TODO: switch this to full namespacers <del> type rsListFunc func(string, metav1.ListOptions) ([]*extensions.ReplicaSet, error) </del> <ins> type RsListFunc func(string, metav1.ListOptions) ([]*extensions.ReplicaSet, error) </ins> type podListFunc func(string, metav1.ListOptions) (*v1.PodList, error) // ListReplicaSets returns a slice of RSes the given deployment targets. // Note that this does NOT attempt to reconcile ControllerRef (adopt/orphan), // because only the controller itself should do that. // However, it does filter out anything whose ControllerRef doesn't match. <del> func ListReplicaSets(deployment *extensions.Deployment, getRSList rsListFunc) ([]*extensions.ReplicaSet, error) { </del> <ins> func ListReplicaSets(deployment *extensions.Deployment, getRSList RsListFunc) ([]*extensions.ReplicaSet, error) { </ins> // TODO: Right now we list replica sets by their labels. We should list them by selector, i.e. the replica set's selector //       should be a superset of the deployment's selector, see https://github.com/kubernetes/kubernetes/issues/19830. namespace := deployment.Namespace

Related discussion:
text: IMO it feels like a bad practice to have mutating resource handlers. The deletePod handler is used for queueing a Recreate deployment once it has no pods running. It should merely look at the ReplicaSets that have owner refs as opposed to using dc.getReplicaSetsForDeployment. The orphaning/adoption dance is already happening inside the reconcilation loop.
I'd like to work on this
feel free to grab it. I can't assign the issue to you so I'll add myself; ping me on the PR when you have one.