elastic / elastic/package-spec
[Discussion] Input packages as "templates"
- Dominant language
- Go
- Stars
- 20
- Forks
- 93
- Avg merge
- 15h 10m
- Merged PRs (30d)
- 12
Description
As an aside on https://github.com/elastic/elastic-package/issues/949, @ruflin proposed the idea of using our new concept of input packages as building blocks or templates for other packages. @jsoriano also had some input so pinging him here 🙂
For example, many packages are - at their core - an extension on top of logfile input or an `httpjson` input. Could we crystalize this concept by allow packages to "extend" an input package as starting point? With functionality like this, we could support things like base fields, processor support, etc across all packages without needing to duplicate/copy-paste config.
One way this might work would be a field like `template_package` in a package's manifest, and the `elastic-package` CLI would be able to read this field to generate the final package archive containing the "extended" set of fields. Another option would be to bake knowledge of these "base packages" into Fleet, but I'm more in favor of keeping all the information a package needs self-contained in its own archive.
This could represent an interesting evolution in how we think about and build packages. Eager to discuss further.
Contributor guide
Assessment
This issue has not been assessed yet.