elastic / elastic/package-spec
[Change Proposal] Creating an allowlist for root level fields
- Dominant language
- Go
- Stars
- 20
- Forks
- 93
- Avg merge
- 15h 10m
- Merged PRs (30d)
- 12
Description
For legacy reasons, which we are now fixing, Packetbeat defines plenty of non-ECS root level fields, recently there was a newer integration (cloud_security_posture), which also defined the same root level fields, causing serious conflicts, which can only be resolved by breaking changes.
To prevent this in the future, I would suggest that we implement a solution to ensure that a manual action is required to implement new root level fields, though certain packages might need to be excempt from this (endpoint, and maybe APM?).
If we could check that:
1. All root level fields are ECS fields, or in a manually curated allow list.
2. All custom fields at least starts with the package name (also datastream name would be best, but that would currently be too hard to resolve).
While this could require a tad bit more discussion, and it would make the dev experience slightly more inconvenient for a very small subset of integrations, it does prevent us to have to do more major breaking changes in the future due to this reason.
The allowlist for non ECS fields should not need to specify every single field, but at least the name of the new root field and its type (object, long, keyword etc).
WDYT?
Contributor guide
Assessment
This issue has not been assessed yet.