Conversation
|
Pinging @elastic/integrations-services (Team:Services) |
💚 Build SucceededExpand to view the summary
Build stats
Test stats 🧪
Steps errorsExpand to view the steps failures
|
|
jenkins run the tests please |
filebeat/input/v2/compat/compat.go
Outdated
There was a problem hiding this comment.
Are you going to resolve this TODO in an upcoming PR?
There was a problem hiding this comment.
There is no common way of how IDs are defined/generated. Let me update this by computing a hash from the configuration object (some parts in libbeat do so).
The cursor based input manager allows you to configure an id setting per input that allows you to have 2 similar inputs with different ID. I think I will move the setting into this layer (will update this PR), so it can be applied to each input (ID will be added to structured logs + can be set by agent in the future).
filebeat/input/v2/compat/composed.go
Outdated
There was a problem hiding this comment.
What is this for? At least it does not clearly come to my mind so it may require a short comment to clarify.
There was a problem hiding this comment.
Ah, this can be removed. I used to export the factory, but added the constructor that returns the expected interface type later. When implementing and exporting a concrete type you still might want the compiler to check that this concrete type implements the supposed interface correctly. Common pattern to do so is:
var _ <interface> = <struct type>{}
or (for interfaces on pointers):
var _ <interface> = (*<struct type>)(nil)
This declares an unused variable, but still triggers the type checker.
An example in the stdlib coming to mind is json.RawMessage.
The idea is to create the compiler error for the author modifying the type, and not the person using the type.
filebeat/input/v2/compat/composed.go
Outdated
There was a problem hiding this comment.
Nit: XXX? Also typo in compining
💚 Build SucceededExpand to view the summary
Build stats
Test stats 🧪
Steps errorsExpand to view the steps failures
|
|
jenkins run the tests please |
This change introduces the input/v2/compat package, that provides a compatibility layer for integration the input v2 API into existing beats functionality. The package provides a function for wrapping v2 inputs into a cfgfile.RunnerFactory (used by autodiscovery, filebet module loading, config file reloading, ....).
What does this PR do?
This change introduces the input/v2/compat package, that provides a
compatibility layer for integration the input v2 API into existing beats
functionality.
The package provides a function for wrapping v2 inputs into a
cfgfile.RunnerFactory (used by autodiscovery, filebet module loading,
config file reloading, ....).
The current state of the full implementation can be seen here and sample inputs based on the new API.
The full list of changes will include:
Test coverage report:
Why is it important?
This PR only introduces the compatiblity layer which will allow use to use new input with existing Beats functionality, but also run new and old architecture in parallel.
Checklist
- [ ] I have made corresponding changes to the documentation- [ ] I have made corresponding change to the default configuration files- [ ] I have added an entry inCHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.Related issues