Support filesystem event triggering?

[hjoliver]

Worth considering?

pyuv Python interface for libuv, a high performance asynchronous networking and platform abstraction library.

Pyuv claims to provide a portable interface to filesystem events (inotify on Linux). Some OSes (or filesystems? - GPFS on AIX) apparently do not support filesystem events at all, but with pyuv maybe cylc could support a generic interface that just fails with a sensible error message if you try to use it on an inappropriate platform.

(credit: Milton Woods, BoM, for the idea).

[slwood]

Note WRT inotify on GPFS it's not so much that GPFS doesn't support inotify, but that inotify cannot 'see' filesystem events that take place on remote hosts. File activity to a GPFS mount on host A will be reported by an inotify instance watching that path on the same host, but it will not be reported by inotify watching the same path on a different host.

This is not always a problem, for instance an ingest daemon watching for new data files pushed from a remote location could use inotify in a GPFS environment if it could be guaranteed that the remote producer always sent data to the host that the ingest daemon was running on -- which may be quite reasonable.

[hjoliver]

@slwood - thanks for the explanation, makes sense (I think you did explain that to me once...).

[hjoliver]

This could almost be closed as superseded by #2339, but I'd better leave it open till will we have some kind of a filesystem triggering plugin.

[hjoliver]

Filesystem event triggering via inotify requires, by definition, some kind of persistent connection that watches for events. The new "xtrigger" PR #2423 is based on intermittent checking, via arbitrary functions, for a trigger to be satisfied. This is not compatible with inotify because an event could happen between checks. In principle we could make a new persistent thread or process in the suite daemon that watches for registered events via inotify and queues them for use in triggering but it's probably not worth the effort because Cylc is used in shared filesystem environments where (as detailed above) events would only be visible if the suite daemon happens to be running on the host where the event originates - which would typically not be the case. On that basis I'm closing this issue. We will probably write xtrigger functions to check for file completion via ".done" files (for example) instead - less elegant but more general and portable.