Ian Brown

It is a true reset, it just doesn't deliver the data exactly at midnight when it's perfectly at zero. I can't believe I'm the first person to run into this....

The issue here is that the integration still can't tell if that zero is due to net metering or a reset.

k8s: 1.30.8 I'll describe one of the nodes giving this trouble, but they should all be identical: ``` Name: k8s-node-4 Roles: Labels: beta.kubernetes.io/arch=arm64 beta.kubernetes.io/os=linux feature.node.kubernetes.io/cpu-cpuid.ASIMD=true feature.node.kubernetes.io/cpu-cpuid.CPUID=true feature.node.kubernetes.io/cpu-cpuid.CRC32=true feature.node.kubernetes.io/cpu-cpuid.EVTSTRM=true feature.node.kubernetes.io/cpu-cpuid.FP=true feature.node.kubernetes.io/cpu-hardware_multithreading=false...

That was done after to stop the scheduler from attempting to push to the arm nodes because of this.

Even if it's in a cordoned state, I would still expect to see the missing pod with a status of Pending right?

The node is uncordoned. I saw snitch run on it just now. How long is the sysdump supposed to take? It has stopped here: ``` Checking all pods labeled with...

Yeah, something's not working with the sysdump -- I tried it again -- if I hit enter after it pauses for over 5 minutes I get those EOF lines. Is...

Also, correct me if I'm wrong, but I thought DaemonSets which the kubearmor-apparmor-cri-o pods come from, by design, don't honor the cordon state of a node. I just tested this...

Any updates? Last I read this was a problem with containers running correctly on arm nodes (or possibly just raspberry pi arm nodes?) In the meantime, is there a way...

Just FYI @rksharma95 I recently tried 1.5.4 but saw the same results.