Markus Lehtonen

i'm a bit disinclined to this kind of filtering hack as it breaks corner cases. For example, in principle the configuration could be something else than a configmap, a direct...

> I figure checking the modification times is more CPU-friendly (just a stat and a time compare) than checksumming Yeah, I think this should actually work. Just briefly looked at...

> The old code fails the test because it just logs a warning and doesn't trigger a reload: I don't think it takes that code path. IIRC nfd-worker actually exits...

> Checking modification time is not robust, because user can make multiple modifications without changing modification time, due to granularity at which time is stored on some of the file...

/ok-to-test

Thanks @Garrybest for the PR. I think this makes sense. I'm sorry I didn't have the time to review the PR this week and now I'm off to summer holidays...

> on the kernel side what would be part of the new `security` feature? SELinux and AppArmor? Currently we only have selinux but I think apparmor would be obvious possible...

I dropped a quick PR for comments #833 re-organizing the CPU security features. This version does not introduce a new feature source but consolidates all cpu security features under `cpu-security.*`....

> Why "cpu-security" instead of "cpu.security"? If it's a subdomain, I think it should be separated by a dot... Domain might be a bit misleading here as it's the name...

Looks unlikely that it's anything NFD-related. I suspect your pod network is not working correctly. Check dns and cni on the node