Incorrect documentation for processors section

[chobostar]

Here is hash:

class{"filebeat":
  processors => {
    "drop_event" => {
      "when" => {"equals" => {"http.code" => 200}}
    },
  },
}
Now to combine these examples into a single definition:

class{"filebeat":
  processors => {
    "drop_fields" => {
      "params"   => {"fields" => ["input_type", "offset"]},
      "priority" => 1,
    },
    "drop_event" => {
      "when"     => {"equals" => {"http.code" => 200}},
      "priority: => 2,
    },
  },
}

but in specification it accepts Array:
Array $processors = [],
https://github.com/pcfens/puppet-filebeat/blob/v4.1.0/manifests/init.pp#L89

[pcfens]

Thanks for catching this - we don't use processors and I must have been moving too quickly.

Let me know if you have issues with the fix. I'll try and get a release cut shortly.

[pcfens]

The fix is in 4.1.1 (just released on the forge)

[georgejolliffe]

Hi Guys,

I'm a puppet novice but since this update i'm unable to get puppet to correctly deploy a working filebeat config.

When I do this with version 4.1.1:
processors => { 'drop_fields' => { 'fields' => ['host'], }, }

I get this on disk of the server:
drop_fields: fields: - host

Before (version 4.1.0) we used to have this:
processors => [ { 'drop_fields' => { 'fields' => ['host'] } } ]

And that resulted in this on disk:
- drop_fields: fields: - host

Notice the hyphen before "drop_fields". If i manually add the hyphen everything works as expected. Any suggestions on what i'm doing wrong here?

[smoeding]

I also see this problem with the latest releases on the forge.

According to https://www.elastic.co/guide/en/beats/filebeat/current/defining-processors.html the value of the processors key clearly must be an array. The template uses @filebeat_config.to_yaml() to generate the config.

I don't see a way that to_yaml would generate an array unless the parameter type is actually an array and not a hash.

[anandinhere]

This is from changelog under v3.0.0 .

Processors should be an array of hashes #157, #156
#157
#156

This seems to be done right. Why is it reverted now? I don't think it's the code that needed a fix here. Rather the documentation is what should be fixed.