Wiping the defaults of filebeats about puppet-filebeat HOT 5 CLOSED

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?

from puppet-filebeat.

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.

from puppet-filebeat.

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.

from puppet-filebeat.

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?

from puppet-filebeat.

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 [email protected]
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
.

from puppet-filebeat.