Wiping the defaults of filebeats

[lswith]

The current implementation of the filebeat.yml template, wipes all the default filebeat settings. It would be better to make sure that if the variable (such as logging), is not passed to the class that it isn't set in the yaml file.

[pcfens]

It's my impression that the defaults are used by filebeat regardless of whether they're commented out in the config file, or not there at all. Is there somewhere that this isn't the case, or are you suggesting that we leave default values commented out if they're not needed?

[lswith]

I was under the impression that:
Logging: {}
Is not the same as
Logging:

I think if the object is empty it shouldn't be put into the template at all.

[pcfens]

Right now every option gets created because of how I'm creating the config file as a hash then converting the hash to YAML.

The downside of doing it this way is that there are extra stubs like this that aren't as pretty as they could be, but the upside is that new configuration options are supported without doing any work. If it's particularly bothersome that the extra config is there, you can use the more explicit config template by setting the conf_template parameter to 'filebeat/filebeat.yml.ruby18.erb'. I'm open to other suggestions if you have any.

At some point I'd like to drop back to one config template if possible, possibly dropping the more future proof template in favor of the Ruby 1.8 one, though it would make the module lag slightly behind with new features. I'll consider this a vote in that column.

[pcfens]

I've done some very minimal testing, and couldn't tell a difference between Logging: {} and Logging: as far as how defaults are handled. There's a good chance I'm not checking all of the cases that might cause problems though - do you have a case that's behaving differently?

[lswith]

I thought it was t working for me but it appears I have been mistaken.
Thanks for double checking on this one
On Sat, 28 May 2016 at 12:07 AM Phil Fenstermacher notifications@github.com
wrote:

I've done some very minimal testing, and couldn't tell a difference
between Logging: {} and Logging: as far as how defaults are handled.
There's a good chance I'm not checking all of the cases that might cause
problems though - do you have a case that's behaving differently?

—
You are receiving this because you authored the thread.

Reply to this email directly, view it on GitHub
#27 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AA-K-6CEsb8HlKBibcG3o9w6kgF8vUx9ks5qFvqqgaJpZM4IkLCh
.