Open jacksgt opened 6 years ago
originally this stemmed from the desire to have a unique ID for each check. essentially the ID gets generated if not present. that said, I see you're point and I'm also of the view that the config really should be immutable..
options: (1) rely on the user specifying a unique ID in the config (2) ID is somewhat deterministically generated (e.g. via hashing), based on all/some of the configuration parameters. therefore doesn't need to be provided. but problematic if a config param used in determining the ID changes, resulting in an ID change
how does option one sound @jacksgt ?
Hi, thanks for the quick answer!
I think both options sound very good, we not even combine them? Let the user - optionally - specify a unique ID (if the consistent data is very important to them) and, if no ID was specified, generate one (the deterministic generation via hashing of parameters seems reasonable).
Personally, I will mostly specify the parameters for each check once and then let it running. Even if I were to change some parameter eventually, I wouldn't be too concerned about the 'old' data.
Hi there,
using the file backend for configuration, redalert writes back into its own configuration file on each start. This is annoying when using configuration management such as Puppet, Ansible, Chef, etc.. as those tools are designed to ensure the system converges in a certain state.
Because redalert uses a slightly different formatting etc. the configuration file is adjusted by (e.g.) Puppet each time, only to be changed by redalert again.
https://github.com/jonog/redalert/blob/master/config/file_store.go#L45
An option to store the state internally without rewriting the config file would be great.