VCL not updated after updating ConfigMap when polling is enabled

[mateusz-kolecki-modivo]

Describe the bug When using -varnish-vcl-template-poll=true and the VCL template is mounted from a ConfigMap then mtime of the mounted file does not change after saving new content to the ConfigMap.

I'm not sure if this is a Kubernetes distro-specific problem but I can reproduce this reliably on my local k3d setup with v1.27.4+k3s1.

It seems to be related to the issue described in 2016 in the Kubernetes issue tracker https://github.com/kubernetes/kubernetes/issues/24215 but it was closed without fixing. The fact that the problem was raised in the Kubernetes repo suggests it is a global issue and not distro-specific.

To Reproduce

1. Install kube-httpcache on k3d managed cluster and use VCL polling (use -varnish-vcl-template-poll=true)
2. Update ConfigMap which holds the VCL template with new VCL template content.

Expected behavior Template should be rendered and Varnish should be reloaded with a new VCL after 15s (at most).

Environment:

• k3d with v1.27.4+k3s1
• kube-httpcache version: v0.8.1

Configuration Any valid VCL

Additional context pkg/watcher/template_watch_poll.go will launch a new gorutine with an infinite loop. On each tick, the loop is using os.Stat() to get stat.ModTime(). The path given to the os.Stat() is actually a symlink to another symlink to the actual file. When the ConfigMap is saved then, the mtime of the file at the end of the symlink chain is updated but the first symlink mtime does not change.

root@varnish-0:/etc/varnish# ls tmpl/ -al
total 0
drwxrwxrwt. 3 root root 100 Apr 12 15:52 .
drwxr-xr-x. 1 root root  28 Apr 12 13:05 ..
drwxr-xr-x. 2 root root  60 Apr 12 15:52 ..2024_04_12_15_52_00.648112414
lrwxrwxrwx. 1 root root  31 Apr 12 15:52 ..data -> ..2024_04_12_15_52_00.648112414
lrwxrwxrwx. 1 root root  23 Apr 12 13:05 default.vcl.tmpl -> ..data/default.vcl.tmpl

[mateusz-kolecki-modivo]

It looks like it was a problem with my setup. The modification time for the symlink is not changing but the function stat.ModTime() seems to look at the symlink target and not the symlink itself. Closing.