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

Drop *_key options in favor of new remap option #3633

Closed
1 task
binarylogic opened this issue Aug 29, 2020 · 2 comments
Closed
1 task

Drop *_key options in favor of new remap option #3633

binarylogic opened this issue Aug 29, 2020 · 2 comments
Labels
domain: config Anything related to configuring Vector domain: vrl Anything related to the Vector Remap Language type: enhancement A value-adding code change that enhances its existing functionality.

Comments

@binarylogic
Copy link
Contributor

Once #3463 is done, we should drop the various *_key options and allow users to remap events to their liking with the new remap option.

  • Preserve backward compatibility by deprecating these options and removing them from our docs.
  • ... will fill out with specific options.
@binarylogic binarylogic added type: enhancement A value-adding code change that enhances its existing functionality. domain: config Anything related to configuring Vector domain: vrl Anything related to the Vector Remap Language labels Aug 29, 2020
@lukesteensen
Copy link
Member

This is an interesting idea but I do think it's missing one facet of the *_key options. Those were very much intended to point out the location of well-known fields (e.g. message, host, timestamp) so that downstream components that use those well-known fields would access them correctly. The current implementation happens to accomplish that by mapping them to specific field names, but a more sophisticated implemenation could have simply recorded some metadata.

If we switch to simply using remap for this, it's not clear how downstream components should know which field to read. It can be just convention around the names, but that seems more brittle and error-prone than the metadata-based solution.

@jamtur01 jamtur01 added this to the 2020-11-09: Augur of Dunlain milestone Nov 6, 2020
@binarylogic binarylogic added the needs: approval Needs review & approval before work can begin. label Nov 6, 2020
@jamtur01 jamtur01 removed the needs: approval Needs review & approval before work can begin. label Nov 6, 2020
@jamtur01 jamtur01 removed this from the 2020-11-09: Augur of Dunlain milestone Nov 6, 2020
@binarylogic
Copy link
Contributor Author

Closing since this will be handled as part of solving schemas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain: config Anything related to configuring Vector domain: vrl Anything related to the Vector Remap Language type: enhancement A value-adding code change that enhances its existing functionality.
Projects
None yet
Development

No branches or pull requests

4 participants