jonog / redalert

:rocket: continuously test all the things - trigger alerts on failure :boom:
MIT License
90 stars 16 forks source link

Do not write back into configuration file #67

Open jacksgt opened 6 years ago

jacksgt commented 6 years ago

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

    err = config.write()
    if err != nil {
        return nil, err
    }

An option to store the state internally without rewriting the config file would be great.

jonog commented 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 ?

jacksgt commented 6 years ago

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.