[chore] Add an RFC for Component Configuration Management Roadmap #14433
Conversation
dmitryax
requested review from
a team,
bogdandrutu,
codeboten and
mx-psi
as code owners
dmitryax
force-pushed
the
add-schemagen-rfc
branch
from
b2ca4fb to
b380e4a
Compare
Merging this PR will not alter performance
|
Replaces open-telemetry#13784 This RFC proposes a roadmap for introducing configuration schemas to OpenTelemetry Collector components. It establishes a schema-first approach in which Go structs, JSON schemas, and documentation are all generated from a single YAML source of truth. This RFC is the result of discussions among contributors involved in this effort: - @atoulme - @evan-bradley - @jkoronaAtCisco - @mx-psi - @pavolloffay Related Issues / PRs: - open-telemetry/opentelemetry-collector-contrib#42214 - open-telemetry#9769 - open-telemetry#14288 - open-telemetry/opentelemetry-collector-contrib#27003
dmitryax
force-pushed
the
add-schemagen-rfc
branch
from
b380e4a to
2b936cd
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #14433 +/- ##
==========================================
+ Coverage 91.81% 91.83% +0.02%
==========================================
Files 677 677
Lines 42536 42680 +144
==========================================
+ Hits 39056 39197 +141
- Misses 2421 2427 +6
+ Partials 1059 1056 -3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
|
||
| **Why YAML schema format for the source of truth?** | ||
| - **Human-readable**: Easier for component developers to author and maintain than JSON | ||
| - **Integration with existing infrastructure**: Natural extension of `metadata.yaml` approach used by `mdatagen` given that it already uses YAML to generate metrics builder configs |
There was a problem hiding this comment.
Should config schema specification be a part of metadata.yaml or separate file?
There was a problem hiding this comment.
I would like to not make strong arguments here. However I believe the metadata.yaml is the natural place. If we are afraid of making it too big, we could just use a reference to another file
| - Produces JSON schemas for config validation | ||
| - Creates synchronized documentation | ||
| - Generated JSON schemas pass validation tests with real collector configurations | ||
| - Generated documentation accurately reflects all configuration options |
There was a problem hiding this comment.
How does the generated documentation differs from the generated JSON schema?
There was a problem hiding this comment.
Documentation is user-friendly Markdown that we currently manually write in README.md for each component. The JSON schema is for machines.
| allOf: | ||
| - $ref: "go.opentelemetry.io/collector/scraper/scraperhelper#/$defs/ControllerConfig" | ||
| - $ref: "#/$defs/MetricsBuilderConfig" | ||
| properties: |
There was a problem hiding this comment.
A validation example would be useful in the example
There was a problem hiding this comment.
What validation example do you mean?
There was a problem hiding this comment.
My assumption is that @pavolloffay means something like
ping_count:
[...]
validation:
greater_than: 0or similar, to show how we can add field validations to the schemas.
evan-bradley
left a comment
evan-bradley
left a comment
There was a problem hiding this comment.
My comments are just naming nitpicks, I think we can adjust those later if needed. Overall this approach makes sense to me.
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description Schemas describing shared configurations used by collector components have been added. This is part of the work related to the implementation of configuration schemas for all components. See more: #14433 <!-- Issue number if applicable --> #### Link to tracking issue Issue: #42214
7 participants
Replaces #13784
This RFC proposes a roadmap for introducing configuration schemas to OpenTelemetry Collector components. It establishes a schema-first approach in which Go structs, JSON schemas, and documentation are all generated from a single YAML source of truth.
This RFC is the result of discussions among contributors involved in this effort:
Related Issues / PRs: