Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for extra inputs #235

Closed
trunet opened this issue Jan 7, 2020 · 5 comments
Closed

Support for extra inputs #235

trunet opened this issue Jan 7, 2020 · 5 comments

Comments

@trunet
Copy link
Contributor

trunet commented Jan 7, 2020

Right now, prospector.yml (should be renamed to inputs.yml), gets a lot of parameters and expects known inputs like log, stdin, docker and syslog.

There're a lot others like tcp, udp, redis, kafka, ... They would be needed to be implemented one by one, with new parameters and dealing with that huge prospector template file.

Therefore I would like to request a feature to change the inputs to be a pure hash representation for inputs, this way everything would be simpler and future proof when new inputs show up.

This would not be backward compatible and could break existing installs after module upgrade. I'm unsure how you would like to deal with this, probably write some manual conversions on the module, add a deprecate notice on the documentation and remove this conversions on a next major release.

Another possibility is to use a new hash parameter like filebeat::inputs_hash or something else and forget about manual conversions and deprecation, but the old code will probably be not maintained because people will tend to use inputs_hash probably.

I can probably work on that and send a PR, just let me know your toughts.

@trunet trunet changed the title pure hash for inputs Support for extra inputs Jan 7, 2020
@pcfens
Copy link
Owner

pcfens commented Jan 7, 2020

A purely hash generated method sounds great to me - I've wanted to switch for a while but haven't had time (any PR help is much appreciated). For now some extra flag on the defined resource is probably the easiest and we'll look to making it the default in some future release.

@trunet
Copy link
Contributor Author

trunet commented Jan 8, 2020

I will implement this, would like your thoughts on best way to do it.

filebeat::inputs is a Hash, filebeat expects an Array of inputs. create_resources() doesn't work on arrays.

My idea is to transform filebeat::inputs into a Variant[Hash, Array] and detects on code if it's a hash follow current implementation otherwise will use pure_hash.yml.erb template.

trunet added a commit to trunet/puppet-filebeat that referenced this issue Jan 8, 2020
)

- Also added .sync.yml to set default rspec moch and configure .travis.yml after pdk update
- Renamed prospector to inputs and prospector5 to prospector
@trunet
Copy link
Contributor Author

trunet commented Jan 8, 2020

Pull request #236

@pcfens
Copy link
Owner

pcfens commented Jan 10, 2020

My only concern with not using the create_resources() function is that it prevents folks from using the defined resource outside of the initial declaration or through hiera.

I wonder if something like a parameter on filebeat::input that accepts a hash that can be converted into a single input might work. When it's present we'd ignore all other options. It'd maintain backwards compatibility and be more future proof, though we'd need some good examples.

Thoughts?

@trunet
Copy link
Contributor Author

trunet commented Jan 10, 2020

I used create_resources(), check PR lines 147-151. And the extra parameter is there, called pure_array. If pure_array is false (default) backward compatibility is maintained.

trunet added a commit to trunet/puppet-filebeat that referenced this issue Jan 10, 2020
)

- Also added .sync.yml to set default rspec moch and configure .travis.yml after pdk update
- Renamed prospector to inputs and prospector5 to prospector
@pcfens pcfens closed this as completed in 8ff5488 Feb 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants