Skip to content

Conversation

atoulme
Copy link
Contributor

@atoulme atoulme commented Sep 8, 2025

Description

Add a RFC to discuss supporting expressing the configuration of a component as a JSON schema.

Link to tracking issue

Relates to #9769 and open-telemetry/opentelemetry-collector-contrib#42214

Copy link

codecov bot commented Sep 8, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.40%. Comparing base (3089704) to head (d3b078e).

Additional details and impacted files
@@            Coverage Diff             @@
##             main   #13784      +/-   ##
==========================================
+ Coverage   91.38%   91.40%   +0.01%     
==========================================
  Files         646      646              
  Lines       42605    42605              
==========================================
+ Hits        38936    38943       +7     
+ Misses       2844     2839       -5     
+ Partials      825      823       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.


We work to add initial schemas by hand in libraries in opentelemetry-collector.

The schemas are added to the library metadata.yaml files.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible not to couple the solution with metadata.yaml? I.e. it can be used as a source of the schema but ideally the tooling should be able to accept alternative location of config schemas.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a JSON schema and in a yaml file, so maybe a couple ways:

  1. We use a yaml anchor and you define the config key in a different section.
  2. You use a JSON schema with a single reference to another schema.

Note if we move the schema to a separate location, we need to be able to resolve it if we lint with checkapi.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looked at your draft PR, and I'm worried that these schema blocks are too big for the metadata.yaml file. Could we have this be a path relative to the metadata.yaml? Could a go.mod link a dependency that embeds the schema? Could we refer to versioned URLs in other repositories? https://github.com/open-telemetry/opentelemetry-collector/pull/13726/files#r2334122066

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jmacd I think you might be right that metadata.yaml becomes a bit big with this, but as I mention above, we can build a reference model so it's possible to link to another file. I also think we need to try, see how difficult or messy it gets, and get wiser.

My goal is to leverage our git tags for any references to versioned schemas, I guess.


We work to add initial schemas by hand in libraries in opentelemetry-collector.

The schemas are added to the library metadata.yaml files.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looked at your draft PR, and I'm worried that these schema blocks are too big for the metadata.yaml file. Could we have this be a path relative to the metadata.yaml? Could a go.mod link a dependency that embeds the schema? Could we refer to versioned URLs in other repositories? https://github.com/open-telemetry/opentelemetry-collector/pull/13726/files#r2334122066

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants