Monitoring of facts files and tag file does not work as expected

[jirihnidek]

Describe the bug If you open fact file or tag file in editor (eg. vim), then monitoring of these files does not work, because vim triggers other events than notify.InCloseWrite or notify.InDelete. vim triggers two events: notify.Rename and notify.Remove

To Reproduce Steps to reproduce the behavior:

1. Start yggd with some fact file using:

   go run ./cmd/yggd --server tcp://localhost:1883 --facts-file /path/to/file.facts \
   --log-level trace --client-id $(hostname)

2. Open /path/to/file.facts in vim, edit the file and save it.

Expected behavior Change of file is detected and new connection status is sent.

Current behavior No change is detected

[subpop]

I have been thinking this over. With the recent change to a facts files (in #221), tags and facts are semantically identical. Is there a reason to keep both? Should we drop one and keep the other?

[jirihnidek]

It seems that tags and facts are supported in yggdrasil-0.2 (rhcd)

Would not break such change (drop e.g. tags) backward compatibility? I mean, would not create it another engineering problem? Tags are stored in toml file. Facts are stored in JSON file. If one is dropped, then we should support some conversion script. Is it worth dropping one file?

[subpop]

Yes, it would break backwards compatibility. We've already done that between 0.2 and 0.3 though, the D-Bus changes, as well as:

• Directive names can no longer contain hyphens. Underscores should be used instead. For example, if your worker was called “package-manager” in 0.2, its name is “package_manager” in 0.3+.
• yggd does not automatically create canonical facts; instead those facts are read from a file path that can be specified by the canonical-facts config file option. It is expected that rhc creates this file when it “connects”.
• The --broker flag has been replaced by a --server flag.

That's partly why I'm considering this idea.