[component] Allow calling component.ValidateConfig at the top level
#12102
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #12102 +/- ##
=======================================
Coverage 91.60% 91.60%
=======================================
Files 461 461
Lines 24678 24678
=======================================
Hits 22607 22607
Misses 1689 1689
Partials 382 382 ☔ View full report in Codecov by Sentry. |
service/config.go
Outdated
| if err := cfg.Pipelines.Validate(); err != nil { | ||
| return fmt.Errorf("service::pipelines config validation failed: %w", err) | ||
| } | ||
|
|
||
| if err := cfg.Telemetry.Validate(); err != nil { | ||
| fmt.Printf("service::telemetry config validation failed: %v\n", err) | ||
| } |
There was a problem hiding this comment.
Are you sure we want to lose these error messages?
There was a problem hiding this comment.
In my opinion we don't, they're essential for users knowing where an error occurred. I think this is motivation for moving ConfigValidator to confmap: we can use the mapstructure tags (or struct field names/map keys/slice indexes/etc.) to recreate these paths automatically.
There was a problem hiding this comment.
If this PR is merged and ConfigValidator is not moved what is the resulting error message when otelcol does the validation?
There was a problem hiding this comment.
It will just be the direct message from the Validate function. So for not configuring any protocols for the OTLP receiver, the Collector will print:
collector server run finished with error: invalid configuration: must specify at least one protocol when using the OTLP receiver
We could still make sure this message is printed inside component, but I think it's undesirable and adds to the reasons why we should move ConfigValidator:
- Simply use the struct field names to create paths and ignore any mapstructure tags. The paths would still be "correct" but may have names that don't match what's in the YAML file.
- Use mapstructure anyway either implicitly or explicitly to do this. This won't have any negative impacts for most users since mapstructure used by confmap and confmap is pretty much universal in the Collector. However I think it's not ideal.
There was a problem hiding this comment.
If we like this, I want to issue the following PRs:
- This PR with just the
ValidateConfigchanges. otelcol and service will still manually callValidateand keep the config paths in the error messages. - Introduce printing the path to
ValidateConfig. - Remove direct calls to
Validatein the codebase. - Move
ConfigValidatorto confmap.
There was a problem hiding this comment.
I support this plan. I think it is important to print the full path to configuration options (like we are doing today or with a new mechanism)
There was a problem hiding this comment.
Ya that sounds good to me.
There was a problem hiding this comment.
@mx-psi @TylerHelmuth this is ready to review.
Follow-up is here: #12108.
evan-bradley
force-pushed
the
toplevel-component-validateconfig
branch
from
7c704fa to
c53dbe7
Compare
|
I'm skipping the contrib tests for now, I'll fix any errors with an |
Description
Updates
component.ValidateConfigto recurse through the entire config object by checking forConfigValidatorimplementations of structs that are under interfaces. Right nowValidateConfigstops at things likecomponent.Configwhich themselves can't implementcomponent.ValidateConfigbecausecallValidateIfPossiblecan only see the interface and not the concrete type before this change.Link to tracking issue
Replaces #12058.
Works toward #11524.