a fsnotify-related risk

[mars1024]

Ocicni now is using fsnotify to load cni config files real-time, but fsnotify has a risk, if we remove cni config path /etc/cni/net.d and recreate it, any changes of this directory will not be detected by fsnotify any more. In other words, ocicni will not work properly after cni config path was removed.

[mars1024]

@dcbw @mrunalp PTAL ~

[mrunalp]

Is that something that can be fixed in fsnotify upstream?

[mars1024]

Is that something that can be fixed in fsnotify upstream?

I don't think so, because fsnotify is using inotify in linux, and inotify is using inode. Maybe we need some changes in ocicni.

[kwilczynski]

@mars1024, what use case would favour removing the entire directory over files within it?

Do you also want to cover the removal of the /etc/cni aside from /etc/cni/net.d? Monitoring /etc to look for /etc/cni deletion can be done, but it would be a bit of an overkill, I think. While keeping the scope to /etc/cni only might be more feasible, I suppose.