jiebi/CodeConvo huggingface dataset:
Code change:
// in node status. By calling this function (GetVolumesToReportAttached), node status should be updated, and the volume // will not need to be updated until new changes are applied (detach is triggered again) verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateAttached, asw) <del> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, true, asw) </del> <ins> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, true, asw, volumeAttachedCheckTimeout) </ins> }

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:
// in node status. By calling this function (GetVolumesToReportAttached), node status should be updated, and the volume // will not need to be updated until new changes are applied (detach is triggered again) verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateAttached, asw) <del> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, true, asw) </del> <ins> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, true, asw, volumeAttachedCheckTimeout) </ins> }

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:
{"name" : "BalancedResourceAllocation", "weight" : 1}, {"name" : "ServiceSpreadingPriority", "weight" : 1}, {"name" : "EqualPriority", "weight" : 1} <del> ] </del> <ins> ], "hardPodAffinitySymmetricWeight" : 10 </ins> }

Related discussion:
text: ( noticed this) HardPodAffinitySymmetricWeight should be in the , not in KubeSchedulerConfiguration If/when fixing this, we need to be careful to do it in a backward-compatilble way.
Do you mean ? It seems scheduler policy config's args can not passed to FitPredicates; it need to update related interface. For the : mark to be deprecated and set scheduler policy config to HardPodAffinitySymmetricWeight if policy config is empty.
Are you working on this? if no, I can take it.
, nop; please go ahead.
/ / / , When reviewing the PR, there's one question on : the default value of is 1, which means the weight (1) will always add to priorities if term matched (), does it our expectation? And the user has to set it to 0 to disable it. IMO, the default value of should be 0.
The value 1 (instead of 0) was chosen so that if you say A must run with B, there is an automatic preference that B should run with A. This seems like reasonable behavior.
Thanks very much; reasonable case to me. But it seems we can not disable it: if set to 0, the default funcs will set it to default (1); similar result to un-set. Anyway, no user complain this now :).
Code change:
numErrs: 0, }, { <ins> name: "invalid duplicate targetports (number with same protocol)", tweakSvc: func(s *api.Service) { s.Spec.Type = api.ServiceTypeClusterIP s.Spec.Ports = append(s.Spec.Ports, api.ServicePort{Name: "q", Port: 1, Protocol: "TCP", TargetPort: intstr.FromInt(8080)}) s.Spec.Ports = append(s.Spec.Ports, api.ServicePort{Name: "r", Port: 2, Protocol: "TCP", TargetPort: intstr.FromInt(8080)}) }, numErrs: 1, }, { name: "invalid duplicate targetports (name with same protocol)", tweakSvc: func(s *api.Service) { s.Spec.Type = api.ServiceTypeClusterIP s.Spec.Ports = append(s.Spec.Ports, api.ServicePort{Name: "q", Port: 1, Protocol: "TCP", TargetPort: intstr.FromString("http")}) s.Spec.Ports = append(s.Spec.Ports, api.ServicePort{Name: "r", Port: 2, Protocol: "TCP", TargetPort: intstr.FromString("http")}) }, numErrs: 1, }, { name: "valid duplicate targetports (number with different protocols)", tweakSvc: func(s *api.Service) { s.Spec.Type = api.ServiceTypeClusterIP s.Spec.Ports = append(s.Spec.Ports, api.ServicePort{Name: "q", Port: 1, Protocol: "TCP", TargetPort: intstr.FromInt(8080)}) s.Spec.Ports = append(s.Spec.Ports, api.ServicePort{Name: "r", Port: 2, Protocol: "UDP", TargetPort: intstr.FromInt(8080)}) }, numErrs: 0, }, { name: "valid duplicate targetports (name with different protocols)", tweakSvc: func(s *api.Service) { s.Spec.Type = api.ServiceTypeClusterIP s.Spec.Ports = append(s.Spec.Ports, api.ServicePort{Name: "q", Port: 1, Protocol: "TCP", TargetPort: intstr.FromString("http")}) s.Spec.Ports = append(s.Spec.Ports, api.ServicePort{Name: "r", Port: 2, Protocol: "UDP", TargetPort: intstr.FromString("http")}) }, numErrs: 0, }, { </ins> name: "valid type - cluster", tweakSvc: func(s *api.Service) { s.Spec.Type = api.ServiceTypeClusterIP

Related discussion:
text: Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Code change:
MASTER_IP="" MINION_IPS="" <ins> KUBECTL_PATH=${KUBE_ROOT}/cluster/ubuntu/binaries/kubectl </ins> # Assumed Vars: #   KUBE_ROOT function test-build-release {

Related discussion:
text: Though I have successfully installed kubernetes via :smiley: , still want to point out this doc missing the step to install . Thus, if user just follow the guide in the doc without having much knowledge about kubernetes, he/she would get error "It looks as if you don't have a compiled kubectl binary" during the step of . Manually install kubectl on at least master node should be necessary (suggest to let user also install on minion node for convenience), any way, the installation step is .
I forget to mention that.I will update the doc this tuned
I update the scripts in pr , you can try it now. I copied the kubectl binary from the kubernetes release and put it in , so there is no extra step for user to manually download . Actually, in the first version of ubuntu k8s deployment, I copied the to every node, but I think it is an overhead, so I removed it.I think this is just enough.
Doc update : Move the kubectl into the PATH, it may need sudo privilege so I decide not do for the user.
Have the same issue, please update the doc ASAP.
Great job :+1:
Also ran into this bug after recklessly running ( instead of ) :)
Code change:
pluginapi.RegisterDevicePluginServer(m.server, m) go m.server.Serve(sock) <del> // Wait till grpc server is ready. for i := 0; i < 10; i++ { services := m.server.GetServiceInfo() if len(services) > 0 { break } time.Sleep(1 * time.Second) </del> <ins> _, conn, err := dial(m.socket) if err != nil { return err </ins> } <ins> conn.Close() </ins> log.Println("Starting to serve on", m.socket) return nil

Related discussion:
text: This is not 100% reproducable in my cluster. There is 20% chance of failing in my environment.
/area hw-accelerators mentioned a root cause that might be due to unit tests sharing the same Unix socket and interfering with each others. cc
Can you please share latest commit id of your code base using ?
Thanks very much, can you try the follow command please:
/assign
The latest commit id of my code base:
I found this is not 100% reproducable in my cluster. There is 20% chance of failing in my environment.
Result of go test command:
/sig scheduling
Thanks!
Hi, does these unit tests pass with PR
I run 100 times without failure.
Good to here that, Nice work! Thanks!
Code change:
return c.check(r) } <ins> // getExcludedChecks extracts the health check names to be excluded from the query param func getExcludedChecks(r *http.Request) sets.String { checks, found := r.URL.Query()["exclude"] if found { return sets.NewString(checks...) } return sets.NewString() } </ins> // handleRootHealthz returns an http.HandlerFunc that serves the provided checks. func handleRootHealthz(checks ...HealthzChecker) http.HandlerFunc { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { failed := false <ins> excluded := getExcludedChecks(r) </ins> var verboseOut bytes.Buffer for _, check := range checks { <ins> // no-op the check if we've specified we want to exclude the check if excluded.Has(check.Name()) { excluded.Delete(check.Name()) fmt.Fprintf(&verboseOut, "[+]%v excluded: okn", check.Name()) continue } </ins> if err := check.Check(r); err != nil { // don't include the error since this endpoint is public.  If someone wants more detail // they should have explicit permission to the detailed checks.

Related discussion:
text: What would you like to be : Add support to the kube-apiserver so that we can disable health-checks via query params. Why is this needed: Currently, the healthz endpoint is inflexible in that any and all health checks are currently executed when the endpoint is hit. Since the kube-apiserver only currently supports a liveness check, this means all persistent health check failures will eventually result in a kubelet driven restart. However, this may not be desirable behavior if you have additional monitoring services layered on top of your control plane. For instance, take the etcd failure from the perspective of the kube-apiserver. Currently, persistent failures during the etcd health check from the api-server healthz endpoint will cause the kube-apiserver to be restarted. This sometimes helps (in the case of a faulty etcd-client connection) but also can be detrimental (the kube-apiserver restarts until the etcd cluster is functioning, then the kube-apiserver bombards the etcd cluster with requests to update local caches, saturating the etcd cluster with requests, causing it to timeout on its own liveness probes and trigger a kubelet-driven restart). Let's say that we could now disable etcd from our liveness health check. Then if we had an external monitoring service, we could ask independently ask etcd if it was healthy and we could also ask the kube-apiserver if it thought etcd was unhealthy. Based on the combination of those answers, we could enable more intelligent responses to certain situation, like restarting the kube-apiserver when it thought etcd was unhealthy but etcd was actually reporting as healthy but not doing so when etcd was actually unhealthy. This feature is backwards-compatible and opt-in. There would be no impact to existing behavior unless these query params are actually used. /sig api-machinery /kind feature
/cc
SGTM
/assign
Code change:
// Score is a list of plugins that should be invoked when ranking nodes that have passed the filtering phase. Score *PluginSet <del> // NormalizeScore is a list of plugins that should be invoked after the scoring phase to normalize scores. NormalizeScore *PluginSet </del> // Reserve is a list of plugins invoked when reserving a node to run the pod. Reserve *PluginSet

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests --What would you like to be : Consolidate ) into Score plugin set in config API. Why is this needed: NormalizeScore extension point is implemented in . We decided to treat NormalizeScore as an "optional" step of Score plugin, see . However, we deferred the removal of due to API review delays. Now that PR was merged. We can start the actual removal from the API and start the API review process. /sig scheduling
/assign
Code change:
}) nc.leaseLister = leaseInformer.Lister() <del> nc.leaseInformerSynced = leaseInformer.Informer().HasSynced </del> <ins> if utilfeature.DefaultFeatureGate.Enabled(features.NodeLease) { nc.leaseInformerSynced = leaseInformer.Informer().HasSynced } else { // Always indicate that lease is synced to prevent syncing lease. nc.leaseInformerSynced = func() bool { return true } } </ins> nc.nodeLister = nodeInformer.Lister() nc.nodeInformerSynced = nodeInformer.Informer().HasSynced

Related discussion:
text: Reboot tests have been failing since 10/12 Dashboard: https://k8s- Sample Failure: https://k8s- This test failure will block 1.13 beta, so please let's fix it before then. Thanks! /sig cluster-lifecycle /kind failing-test /priority important-soon
Note: this failure is similar to but is not the same failure, according to This is a consistent failure rather than a flake, and all nodes are failing to reboot. It's also been failing consistently since 10/11. /cc
Copying my notes here: Looking at one recent test run: The test failed because kubelet never became "not ready": When looking at one of the kubelet logs, I do see that kubelet had problems making Node updates to the api server: Errors continue until kubelet is restarted 8 minutes later (the test times out at 2 minutes):
So it seems like even though kubelet is unable to update its Node status, the Node is still showing up as Ready
Adding sig-node to this discussion: /sig node
I'm trying to repro on a dev 1.11/1.12 cluster so we can get master logs for the node controller
/cc adding from sig-node
/assign
was the only PR that went in during that time (if we don't count infra or gke changes). This PR touches the node controller and changes the node heartbeat, so it could be the culprit. I was able to grab the logs from the mater was it was still up. Snippet from the kube-controller- showed a lot of error: The PR author is out for a couple of days, so he cannot investigate. I can look at it later today maybe. If anyone from GKE wants to help, I can send you all the logs.
The node controller doesn't seem to be working at all as it wasn't marking the nodes not ready. suggested that the api group may not have been whitelisted in GKE, so I checked and that seemed to be true. We can whitelist it, but for an alpha feature, it should not be properly gated and not affect production. We can revert PR to unblock release, and wait for to re-submit a patched PR. /cc
Thanks for debugging this! Just got time to take a quick look. Does it mean should also be put behind the feature gate?
Code change:
}) nc.leaseLister = leaseInformer.Lister() <del> nc.leaseInformerSynced = leaseInformer.Informer().HasSynced </del> <ins> if utilfeature.DefaultFeatureGate.Enabled(features.NodeLease) { nc.leaseInformerSynced = leaseInformer.Informer().HasSynced } else { // Always indicate that lease is synced to prevent syncing lease. nc.leaseInformerSynced = func() bool { return true } } </ins> nc.nodeLister = nodeInformer.Lister() nc.nodeInformerSynced = nodeInformer.Informer().HasSynced

Related discussion:
text: I think reverting is a good option to unblock stuff. - creating listed may not be necessary, but setting HasSynced is (so if we have to put it after feature gate, we should put both).
Is there any guideline on how to revert my original PR ? I haven't done it before. Just revert in my fork and submit a new PR? I also just put up a fix PR . I am fine with either submitting the fix PR or revert my original PR first.
/reopen /assign I will manually close this after verifying the bots.
Reopening this issue. <detailsIn response to : /reopen /assign I will manually close this after verifying the bots. 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 is passing in the latest test run. Thanks for the quick turnaround
Nice! Closing this now. /close
Closing this issue. <detailsIn response to : Nice! Closing this now. /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Code change:
func TestIsCurrentInstance(t *testing.T) { cloud := &Cloud{ Config: Config{ <del> VMType: vmTypeVMSS, </del> <ins> VMType: vmTypeStandard, </ins> }, } testcases := []struct {

Related discussion:
text: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: If computer name prefix does not match VMSS name, then Azure cloud provider will use VMSS API instead of using metadata service data. This leads to throttling, because every affected kubelet is making API requests. What you expected to happen: Azure cloud provider should use metadata service data instead of calling VMSS API when instance is current. How to reproduce it (as minimally and precisely as possible): Set computer name prefix of the VMSS to something different than default. You should observe Azure provider making requests to the VMSS API rather than using metadata service, which leads to throttling if you have multiple kubelets with this bug. Anything else we need to know?: This is bug was introduced by - returns false even if instance is current, because it expects node name to match VMSS name + instance id, however node name is derived from the computer-name-prefix which can be different than VMSS name. Node name should be matched against , not against . Environment: Kubernetes version (use ): 1.18.x and higher Cloud provider or hardware configuration: azure /sig cloud-provider
/sig cloud-provider
/area provider/azure
CC
/remove-sig cloud-provider /sig cloud-provider (trying to remove the label)
/sig cloud-provider
Thanks for the reporting. Unfortunately, computer name prefix is not included in IMDS, so it can't be used without VMSS API for constructing the NodeName. Would check what could we do to workaround the issue.
Can you memorize the computer name prefix in the first request to the Azure API and then use it for the isCurrentInstance check?
opened to fix the issue. Would you like to have a look?
I can confirm that your change should fix the problem I reported. Do you know if your fix will be to 1.18.x?
is working on the cherry pick
Thank you for quick fix!
Code change:
parameters[k] = v.(string) } } <ins> if snapshotProvider, ok := snapshotClass.Object["driver"]; ok { snapshotter = snapshotProvider.(string) } </ins> } return testsuites.GetSnapshotClass(snapshotter, parameters, ns, suffix)

Related discussion:
text: <!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: On running kubetest with external storage driver option with driver name "", encountered error of flag redefinition. The issue happens because: As part of this patch , a flag is defined for number of inline volumes. The driver name is used to construct the flag name. Thus, when running tests on an externally provided driver (in this instance the Persistent Disk CSI driver) with driver name "", a redefinition error happens since the ephemeral test suite code path is executed once for and once for External PD CSI driver. [example run command: kubetest --test --check-version-skew=false --testargs="-- --storage.testdriver=/path/to/gcp-compute-persistent-disk-csi-driver/test/k8s-integration/config/test-" Test config looks something like this: { StorageClass: FromFile: ... SnapshotClass: FromFile: ... DriverInfo: Name: ... } ] What you expected to happen: Test should run and succeed. How to reproduce it (as minimally and precisely as possible): Use an test-, with driver name as "", and run kubetest with focus as "External.Storage" kubetest --test --check-version-skew=false --testargs="-- --storage.testdriver=/path/to/gcp-compute-persistent-disk-csi-driver/test/k8s-integration/config/test-" Anything else we need to know?: Possible fixes options: , (), when using a FromFile or FromExistingClassName option to pass in SnapshotClass information, pickup the provisioner name from the class definition's "driver" field. the flag which has a dependency on driver names. (need to understand the impact of removing the command line flag) Environment: Kubernetes version (use ): latest master Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig storage
/assign Do you know why this parameter is set as a flag and not a part of the ?
To me, is something that defines what the driver can do. This flag is about what the test does and not related to driver capabilities.