Cherry-pick #17655 to 7.x: Start to split filebeat/channel up#19654
Cherry-pick #17655 to 7.x: Start to split filebeat/channel up#19654urso merged 1 commit intoelastic:7.xfrom
Conversation
(cherry picked from commit bc8123a)
|
Pinging @elastic/integrations-services (Team:Services) |
💔 Build FailedExpand to view the summary
Build stats
Test stats 🧪
Steps errorsExpand to view the steps failures
Log outputExpand to view the last 100 lines of log output
|
|
jenkins run tests |
|
jenkins run the tests please |
1 similar comment
|
jenkins run the tests please |
Cherry-pick of PR #17655 to 7.x branch. Original message:
What does this PR do?
The Factory in filebeat/channel package wraps the publisher pipeline, in order to add some shutdown propagation support, but also to modify the beat.ClientConfig when an input is configured. The channel.Connector reads and applies common settings for all inputs, configures Guaranteed sending, and hooks up a global counter with each beat.Client, in order to track live events.
This change reduces the responsibilities of the factory, by splitting them up. A package libbeat/publisher/pipetool is introduced to provide helper functions for modifying a beat.Pipeline before and after Connect. This centers support for more functionality on the beat.PipelineConnector and beat.Client interfaces, instead of incompatible types wrapping the pipeline.
The Factory in filebeat/channel will not modify the input configuration or the beat.Client anymore. It is only required to add shutdown signaling to the pipeline (which we will remove in the future as well). The filebeat/channel provides a helper function for decorating a cfgfile.RunnerFactory, such that common configurations are still applied as before. Again, by centering around a small set of common interfaces, reduce the effort to integrate future input refactorings.
All in all, the filebeat/channel factory still provides the same functionality as before (for now), but splits the different functionalities into 3 separate interfaces.
Why is it important?
Support ease of integration of new input API, based on RunnerFactory only.
Checklist
- [ ] I have made corresponding changes to the documentation- [ ] I have made corresponding change to the default configuration files- [ ] I have added tests that prove my fix is effective or that my feature worksCHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.Related issues