Change:
// either 0 or between 10000 and 2e9. // Please refer, https://github.com/kubernetes/kubernetes/pull/95345#discussion_r501630942 // for more information. <del> "UsageNanoCores":       gomega.SatisfyAny(gomega.BeZero(), bounded(10000, 2e9)), </del> <ins> "UsageNanoCores":       gomega.SatisfyAny(gstruct.PointTo(gomega.BeZero()), bounded(10000, 2e9)), </ins> "UsageCoreNanoSeconds": bounded(10000000, 1e15), }), "Memory": ptrMatchAllFields(gstruct.Fields{

Discussion:
links to specific failures in spyglass: /sig node
/triage accepted
/assign
any updates on this?
Will take a look at this week.
It looks has the same symptoms as - FYI Looks as cadvisor stats provider(e2e node still runs with docker) does not provide relevant stats. It looks like some cadvisor bug, because we only fethc the data from the cadvisor.
/area kubelet cadvisor
/priority important-soon
/cc
/milestone v1.22
/unassign /assign
Are there examples of recent flakes for this? Looking at it seems pretty green for this test over the past 2 weeks.
It does not happen often, but still happen, see -
Also, take into account that we mitigated one of the similar errors via
That's failing often enough to be considered flaky; I have seen this test fail frequently on presubmit jobs.
Flaking very frequently on the swap ubuntu periodic:
this is not a regression, our suggestion is not block release on it. feel free to remove the milestone
Taking a closer look. Some failures from Failure 1: Failure 2: Failure 3:
hmm, I'm not sure if I understand the failure correctly. It looks like the test gets back for and expects that it will match either zero or be = . The test code expects either 0 or between and 2e9. Based on error message, it in fact look like it's getting back 0: so I'm a bit confused why this check is failing. Am I misunderstanding the failure or does the line not do what we are expecting? /cc who looked who spent some time looking at this as part of
Also by the way, the failures in ubuntu swap job seem to be caused by a different reason than the kubelet master conformance job. Those failures seem to be due to MemoryStats: e.g. Perhaps memory stats may be impacted by swap being enabled?
I tried to repro the failures in by making the below patch (to force to always be zero). With this patch, the test fails consistently: despite the fact that zero should be valid and passing for the test So this makes me think that the problem is that the is not actually doing what we expect.
I think the problem is that is doing a uint64 pointer comparison to uint64.

expected is matcher expects The following patch to test results in test passing when zero is returned:
/reopen This appears to be flaking a lot per triage, I'm also seeing it on PRs
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
Since this is against milestone v1.22, let me close this and potentially open a new issue as the current failures don't match. /close
Closing this issue. <detailsIn response to : Since this is against milestone v1.22, let me close this and potentially open a new issue as the current failures don't match. 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