[WIP] fswatch: add cross-platform filesystem watcher#349
Conversation
k8s-ci-robot
added
the
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dims The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
approved
dims
force-pushed
the
add-fswatch
branch
3 times, most recently
from
06a3d7c to
d9b2366
Compare
A small Kubernetes compatibility layer that removes direct
github.com/fsnotify/fsnotify dependencies from the Linux build closure.
Linux uses raw inotify(7) (epoll + pipe wakeup) inline; non-Linux
platforms wrap fsnotify behind a build-tag-isolated adapter so fsnotify
is absent from production Linux binaries.
Public surface:
type Watcher
func NewWatcher() (*Watcher, error)
(Watcher) Add / Remove / Events / Errors / Close
type Event { Name, Op } / (Event) Has(Op)
type Op ( Create | Write | Remove | Rename | Chmod )
ErrClosed, ErrNonExistentWatch, ErrEventOverflow
func WatchFile(ctx, path, onChange, ...FileOption) error
WithRecheckInterval, WithFallbackPolling,
WithInitialCallback, WithErrorHandler
func WatchDir(ctx, dir, onChange, ...DirOption) error
WithDirRecheckInterval, WithDirErrorHandler
WatchDir watches dir non-recursively; on Add(dir) failure (initial or
self Remove/Rename) it reports through the error handler and keeps
ticking onChange on the recheck interval, retrying Add(dir) on each
tick until the watch comes back online — so manifest reloaders do not
silently stop on transient ENOENT/ENOSPC.
WatchFile watches the parent directory so atomic-rename updates are
observed; WithRecheckInterval fires onChange unconditionally each tick
to support callers that retry transient apply failures, while
filesystem events still go through an lstat-based change check.
WithInitialCallback fires after the watch (or fallback poll) is in
place to avoid a race window with the first event.
Add and Remove hold the lifecycle mutex across the underlying syscall
so a concurrent Close cannot tear down the FD mid-call.
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
| require github.com/go-logr/logr v1.2.0 // indirect | ||
| require ( | ||
| github.com/go-logr/logr v1.2.0 // indirect | ||
| golang.org/x/sys v0.13.0 // indirect |
There was a problem hiding this comment.
This needs CVE patches pretty often, and now gets brought into the tree for anyone using k8s.io/utils which almost didn't have dependencies before (IMHO we should really try to factor out go-spew at some point, klog seems reasonable)
|
ok but why? If we don't trust fsnotify, then we shouldn't trust it on Windows either, and if we do, then we don't need to get rid of it on Linux... (Alternatively, to the extent that there's an implied "we don't actually care about Windows", we could just have |
4 participants
A small Kubernetes compatibility layer that removes direct github.com/fsnotify/fsnotify dependencies from the Linux build closure. Linux uses raw inotify(7) (epoll + pipe wakeup) inline; non-Linux platforms wrap fsnotify behind a build-tag-isolated adapter so fsnotify is absent from production Linux binaries.
WatchDir watches dir non-recursively; on Add(dir) failure (initial or self Remove/Rename) it reports through the error handler and keeps ticking onChange on the recheck interval, retrying Add(dir) on each tick until the watch comes back online — so manifest reloaders do not silently stop on transient ENOENT/ENOSPC.
WatchFile watches the parent directory so atomic-rename updates are observed; WithRecheckInterval fires onChange unconditionally each tick to support callers that retry transient apply failures, while filesystem events still go through an lstat-based change check. WithInitialCallback fires after the watch (or fallback poll) is in place to avoid a race window with the first event.
Add and Remove hold the lifecycle mutex across the underlying syscall so a concurrent Close cannot tear down the FD mid-call.
What type of PR is this?
/kind feature
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note: