Suppressing logging of configuration files on init #237
Conversation
|
Tests breakage has been occurring already for Ruby 1.8.7. |
|
And yes, that logging is output on |
|
@sigv Yeah, we really need to fix the test failures, sorry :( But we aren't holding up PRs on them at least. Is there a way to write that info out only when debugs are enabled? I would guess something like |
|
I could switch it over, but the |
|
That is, if I just switch the |
|
Well, poop. It does seem helpful to print the name of the file used when in debug mode, If you move it down a line, after the config is read, would that help? Technically it shouldn't say |
|
A quick glance suggest that it probably isn't that easy. If you can find a way to preserve this info somehow, great, but if not I think it's beneficial to merge as is so that silent operation is actually silent. Let me know. |
|
I will look into this in-depth later today then to make a nicer change.
Will keep it on the same branch & PR for historical purposes, so please
hold back on this PR until then. 👍
|
Up until now, you could not directly use `eyaml` in shell scripting along with a configuration file since each such invocation resulted in additional debugging logs being included in the output. Those logs can be dropped since they are informing the user about well documented behavior (see README) for the sake of allowing scripting encyption and decryption in a simple non-interactive fashion with plain pipes. > [hiera-eyaml-core] Loaded config from /home/user/.eyaml/config.yaml
We do want to log where our configuration comes from as mentioned in #237 but that should take place on the `debug` level and not the `info` level, since the behavior is documented in the README and should only appear in verbose logs. Additionally, that kind of logging should take place after all the options have been parsed, since it matters what kind of verbosity users want to have output.. and we do not know that until after parsing. That results in a little bit of messy code where the sources of the options are passed along with the options themselves, but also means possible expansion in the future. Maybe.
|
Tests seem to be passing locally for me. Behavior wise, this like an acceptable change to me - only output where the configuration is being loaded from, when the user requests additional verbosity. Example demo log output: I would however appreciate comments on my Ruby code styling since I am not really used to writing Ruby. 😄 |
|
Seems Ruby-ish to me. Thanks! |
|
Any plans on reviewing and eventually merging this change? 🤔 |
|
@sigv Sorry! I think I was on my phone when I reviewed this and forgot to hit merge. Thanks! |
We do want to log where our configuration comes from as mentioned in voxpupuli#237 but that should take place on the `debug` level and not the `info` level, since the behavior is documented in the README and should only appear in verbose logs. Additionally, that kind of logging should take place after all the options have been parsed, since it matters what kind of verbosity users want to have output.. and we do not know that until after parsing. That results in a little bit of messy code where the sources of the options are passed along with the options themselves, but also means possible expansion in the future. Maybe.
Right now subcommand.rb logs something along the following on start-up if a configuration file exists:
That kind of debugging information is understandable and can be helpful for seeing how your configuration is applied, but it is very bad for non-interactive use. Additionally, the behavior for loading these configuration files is documented in the README, so I am proposing removing those logs for the benefit of being able to properly script
eyaml encryptas well aseyaml decrypt.