Change:
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?
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

Discussion:
}) 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