-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Enhance config validation by Instantiating service during dryrun.
#12488
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enhance config validation by Instantiating service during dryrun.
#12488
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #12488 +/- ##
==========================================
+ Coverage 91.57% 91.60% +0.03%
==========================================
Files 483 483
Lines 26383 26386 +3
==========================================
+ Hits 24160 24172 +12
+ Misses 1762 1756 -6
+ Partials 461 458 -3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
89f448f to
754e9a7
Compare
|
Some tests are failing, which are not related to this PR. Any guidance would be helpful. |
mx-psi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the errors that were not reported before that are reported after this change? Can we instead statically validate those?
|
Feel free to ignore the errors, they are not related to this PR |
|
@mx-psi Thanks for the quick response!
This approach should catch all errors in the pipeline configuration. I am not aware of it all, but here are a couple of examples. Especially for 1. Improper Connector Use invalid_config.yamlreceivers:
otlp:
protocols:
grpc:
exporters:
debug:
connectors:
forward:
service:
pipelines:
logs/in:
receivers: [otlp]
processors: []
exporters: [forward]
logs/in2:
receivers: [ otlp ]
processors: [ ]
exporters: [ forward ]
logs/out:
receivers: [otlp]
processors: []
exporters: [debug]
traces:
receivers: [ otlp ]
processors: [ ]
exporters: [ forward ]
metrics:
receivers: [ forward ]
processors: [ ]
exporters: [ debug ]Before: No error detected Proposed Change: Error: failed to build pipelines: connector "forward" used as exporter in [logs/in2 logs/in] pipeline but not used in any supported receiver pipeline
2025/02/25 16:58:09 collector server run finished with error: failed to build pipelines: connector "forward" used as exporter in [logs/in2 logs/in] pipeline but not used in any supported receiver pipeline
2. Unused Connector invalid_config.yamlreceivers:
otlp:
protocols:
grpc:
http:
exporters:
debug:
connectors:
forward:
service:
pipelines:
logs/out:
receivers: [forward]
processors: []
exporters: [debug]Before: No error detected Proposed Change: Error: failed to build pipelines: connector "forward" used as receiver in [logs/out] pipeline but not used in any supported exporter pipeline
2025/02/26 10:40:53 collector server run finished with error: failed to build pipelines: connector "forward" used as receiver in [logs/out] pipeline but not used in any supported exporter pipeline
2. Cycle in the Pipeline invalid_config.yamlreceivers:
otlp:
protocols:
grpc:
exporters:
debug:
connectors:
forward:
service:
pipelines:
traces/in:
receivers: [forward]
processors: [ ]
exporters: [forward]
traces/out:
receivers: [forward]
processors: [ ]
exporters: [forward]Before: No error detected Proposed Change: Error: failed to build pipelines: cycle detected: connector "forward" (traces to traces) -> connector "forward" (traces to traces)
2025/02/26 11:12:53 collector server run finished with error: failed to build pipelines: cycle detected: connector "forward" (traces to traces) -> connector "forward" (traces to traces)
|
16f3e68 to
bce7fac
Compare
bogdandrutu
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer the DryRun to not have to start the collector, what do we miss that we need to do this?
These are the error that current 1. Improper Connector Use invalid_config.yamlreceivers:
otlp:
protocols:
grpc:
exporters:
debug:
connectors:
forward:
service:
pipelines:
logs/in:
receivers: [otlp]
processors: []
exporters: [forward]
logs/in2:
receivers: [ otlp ]
processors: [ ]
exporters: [ forward ]
logs/out:
receivers: [otlp]
processors: []
exporters: [debug]
traces:
receivers: [ otlp ]
processors: [ ]
exporters: [ forward ]
metrics:
receivers: [ forward ]
processors: [ ]
exporters: [ debug ]Before: No error detected Proposed Change: Error: failed to build pipelines: connector "forward" used as exporter in [logs/in2 logs/in] pipeline but not used in any supported receiver pipeline
2025/02/25 16:58:09 collector server run finished with error: failed to build pipelines: connector "forward" used as exporter in [logs/in2 logs/in] pipeline but not used in any supported receiver pipeline
2. Unused Connector invalid_config.yamlreceivers:
otlp:
protocols:
grpc:
http:
exporters:
debug:
connectors:
forward:
service:
pipelines:
logs/out:
receivers: [forward]
processors: []
exporters: [debug]Before: No error detected Proposed Change: Error: failed to build pipelines: connector "forward" used as receiver in [logs/out] pipeline but not used in any supported exporter pipeline
2025/02/26 10:40:53 collector server run finished with error: failed to build pipelines: connector "forward" used as receiver in [logs/out] pipeline but not used in any supported exporter pipeline
2. Cycle in the Pipeline invalid_config.yamlreceivers:
otlp:
protocols:
grpc:
exporters:
debug:
connectors:
forward:
service:
pipelines:
traces/in:
receivers: [forward]
processors: [ ]
exporters: [forward]
traces/out:
receivers: [forward]
processors: [ ]
exporters: [forward]Before: No error detected Proposed Change: Error: failed to build pipelines: cycle detected: connector "forward" (traces to traces) -> connector "forward" (traces to traces)
2025/02/26 11:12:53 collector server run finished with error: failed to build pipelines: cycle detected: connector "forward" (traces to traces) -> connector "forward" (traces to traces)
|
|
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
|
@bogdandrutu PR #12681, implements validation without instantiating the service, please take a look. |
bce7fac to
e53a1f7
Compare
|
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description As described in [#8721](#8721), the current `validate` command cannot capture improper connector usage errors during a dry run. One proposed solution _(as mentioned in [this comment](#8721 (comment) is to surface configuration errors by instantiating the service during the dry run. However, reviewers preferred statically verifying the errors over instantiating the service (see the [PR #12488 comments](#12488)). The validation logic for connectors is located in the [`service/internal/graph`](https://github.com/open-telemetry/opentelemetry-collector/blob/1daa315455d02bac90185027878d858ba08a0f07/service/internal/graph) package. In the discussion of [PR #12681](#12681), it was concluded that instantiating the graph is the better approach (see [this comment](#12681 (comment))). Finally, this PR uses the `graph.Build()` method to surface configuration errors during the dry run. <!-- Issue number if applicable --> #### Link to tracking issue Fixes #8721 #12535 <!--Describe what testing was performed and which tests were added.--> #### Testing <!--Describe the documentation added.--> #### Documentation <!--Please delete paragraphs that you did not use before submitting.--> --------- Signed-off-by: sudipto baral <[email protected]>
bogdandrutu
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please rebase
| mockMap: map[string]string{ | ||
| "number": "123", | ||
| }, | ||
| expectErr: true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a version without error.
| if err = conf.Marshal(cfg); err != nil { | ||
| return fmt.Errorf("could not marshal configuration: %w", err) | ||
| } | ||
| _ = conf.Marshal(cfg) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why skip the error?
|
We can close this one as #12712 was the final PR which is now merged. @bogdandrutu |
Description
As mentioned in #8721 (comment), we can surface configuration errors by instantiating the service during a dry run.
Expanding on this idea, this PR enhances configuration validation. The validate command will now capture all validation errors that would prevent the collector from starting.
Link to the tracking issue
Fixes #8721
Testing
Added unit tests. Also, a few scenarios and example output are given below. I will add more unit tests if necessary.
1. Improper Connector Use
invalid_config.yaml
Before: No error detected
Proposed Change:
2. Unused Connector
invalid_config.yaml
Before: No error detected
Proposed Change:
2. Cycle in the Pipeline
invalid_config.yaml
Before: No error detected
Proposed Change:
Note
I removed the following log as it seemed redundant to me and it is also surfaced during validation. Let me know if we absolutely need to keep it
opentelemetry-collector/service/service.go
Line 193 in 5812712