configfile: allow selecting slow watch behavior via env var #58
Conversation
HARAKA_CONFIG_CUSTOM_DIR sets custom config dir HARAKA_CONFIG_SLOWWATCH selects slow watch behavior
|
Let's discuss! |
|
I'm not a fan of the name "SLOWWATCH." What you're doing here isn't watching at all but polling. |
|
No shit captain. Have you read the docs? |
|
Anyway, is the varname the only thing that annoys you? |
Yes. I think the 'on' trigger needs to have pull_request added. I'm making that change in another PR. |
|
|
||
| Auto-reload is not supported on an FS that doesn't implement proper file changes notify mechanism. | ||
|
|
||
| Imagine you've got several Haraka nodes that keep their config dir on a network FS. You have updated a configuration file on the network server and would like to let all Haraka nodes know your file has been updated. For that, you have to login to all your Haraka nodes and `touch` the relevant config file manually. Obviously, this really resembles plain old `scp` copy, except that you only touch files instead of copying data. It almost makes no point of using a network FS then. So, for those people who desire all this drama to be irrelevant, we've made a special option available that allows to poll files for changes periodically instead of relying on notify mechanism. It is very slow and triggers traffic on network FS during the poll, but it's the only way around. Set `HARAKA_CONFIG_SLOWWATCH` env var to desired poll interval (> 10 recommended) and you'll have your config files reloaded (in > 15 secs) after the file update. |
There was a problem hiding this comment.
That's a very verbose way to say, "I didn't like my manual implementation of rdist. Here's a slow alternative to fs.watch() for platforms and/or filesystems where fs.watch is not supported."
There was a problem hiding this comment.
Correct, it just details the reasoning.
|
This PR seems abandoned. It doesn't pass lint tests and has no activity in half a year. If it were updated to pass the CI tests and replace the very long-winded explanation of motivation (you can document that here and link to it if you wish) with a succinct "this is how it works," paragraph, I'd be inclined to merge. |
|
It's the first time ever I see a patch being rejected on basis of containing too much documentation. Usually, it's the other way around. We won't get far with such attitude. |
It's not. This PR hasn't been merged because it is failing lint tests. I told what you what I want to see before I merge it. There are others with merge access who may not mind wading through a wall of text to find the docs for the config options.
You have certainly demonstrated that. You asked for discussion but have been hostile towards it. And curiously, you introduce env vars after calling them a security disaster in #39 |
override watch behavior by ENV vars
HARAKA_CONFIG_CUSTOM_DIRsets custom config dirHARAKA_CONFIG_SLOWWATCHselects slow watch behaviorA fix for the case when file is gone but
config.getkeeps returning pre-deletion data from cache.