Skip to content
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

[service] Validate pipeline type against component types #9257

Merged
merged 23 commits into from
Apr 10, 2024

Conversation

ycombinator
Copy link
Contributor

@ycombinator ycombinator commented Jan 10, 2024

Description:

This change adds another layer of validation to pipelines. It validates that all the components in a pipeline are of the same type as the pipeline.

For example, if a metrics pipeline contains a traces-only receiver, the otelcol validate -config ... command will fail.

Link to tracking Issue:
Fixes #8007.

Testing:
Added unit test + existing tests are passing.

Documentation:
godoc.

@ycombinator ycombinator changed the title Validate pipeline types service: validate pipeline type against component types Jan 10, 2024
@ycombinator ycombinator changed the title service: validate pipeline type against component types [service] validate pipeline type against component types Jan 10, 2024
@ycombinator ycombinator changed the title [service] validate pipeline type against component types [service] Validate pipeline type against component types Jan 10, 2024
@ycombinator ycombinator changed the title [service] Validate pipeline type against component types WIP [service] Validate pipeline type against component types Jan 10, 2024
@ycombinator ycombinator force-pushed the validate-pipeline-types branch 2 times, most recently from 2193534 to 2da328c Compare January 11, 2024 22:17
@ycombinator ycombinator changed the title WIP [service] Validate pipeline type against component types [service] Validate pipeline type against component types Jan 12, 2024
@ycombinator ycombinator marked this pull request as ready for review January 12, 2024 00:42
@ycombinator ycombinator requested review from a team and bogdandrutu January 12, 2024 00:42
@@ -141,6 +146,39 @@ func New(ctx context.Context, set Settings, cfg Config) (*Service, error) {
return srv, nil
}

func Validate(ctx context.Context, set Settings, cfg Config) error {

Choose a reason for hiding this comment

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

Why public?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because it's being called from the otelcol package.

Copy link
Contributor

Choose a reason for hiding this comment

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

@ycombinator please take this as strong feedback that adding new public API to packages is discouraged at this time. Please add a godoc comment and prepare to discuss why this must be public.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Got it, thanks for letting me know about trying not to increase the public API surface. It makes sense. Let me see if I can reimplement this functionality without adding to the public API, otherwise I will add a godoc here.

Copy link
Contributor Author

@ycombinator ycombinator Mar 5, 2024

Choose a reason for hiding this comment

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

Hmmm, I'm not really seeing an easy way around adding a new public API here given that the implementation of this function is using symbols from internal packages. But if there's some way to accomplish not adding
a new public API, I'm open to suggestions on how to go about it.

For now, I've added a godoc comment to this function as suggested.

Copy link
Member

Choose a reason for hiding this comment

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

Could we get the same result by just calling New? Is there a side effect to calling New which is being avoided by having a separate function?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the suggestion, @djaglowski - it totally works! Not sure why I didn't consider that much simpler approach 🤦. Anyway, implemented in e373dd9.

Comment on lines 131 to 134
// validate the configuration
if err := validate(ctx, set, cfg, srv.telemetrySettings); err != nil {
return nil, err
}

Choose a reason for hiding this comment

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

Would we not find out about this error anyway when we call graph.Build?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, that's true. I was trying to validate it even earlier than that but you're right — it doesn't really matter. Removing this call, thanks for catching it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed in 8729b39.

Comment on lines 155 to 149
telSettings := servicetelemetry.TelemetrySettings{
Logger: tel.Logger(),
TracerProvider: tel.TracerProvider(),
MeterProvider: noop.NewMeterProvider(),
}

Choose a reason for hiding this comment

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

Why not using noop everywhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you mean for the Logger and TracerProvider fields? I'm not seeing anything in the noop package that could be used to initialize those fields.

Copy link
Contributor

github-actions bot commented Feb 1, 2024

This PR was marked stale due to lack of activity. It will be closed in 14 days.

@github-actions github-actions bot added the Stale label Feb 1, 2024
@ycombinator
Copy link
Contributor Author

PR is still active; waiting on review.

@ycombinator ycombinator force-pushed the validate-pipeline-types branch from 8729b39 to 8eb53a6 Compare February 1, 2024 13:00
@github-actions github-actions bot removed the Stale label Feb 2, 2024
Copy link

codecov bot commented Feb 12, 2024

Codecov Report

Attention: Patch coverage is 82.05128% with 14 lines in your changes are missing coverage. Please review.

Project coverage is 90.97%. Comparing base (c6d1482) to head (da1f5d8).
Report is 3 commits behind head on main.

❗ Current head da1f5d8 differs from pull request most recent head 58523a4. Consider uploading reports for the commit 58523a4 to get more accurate results

Files Patch % Lines
receiver/receivertest/nop_receiver.go 23.52% 13 Missing ⚠️
otelcol/collector.go 94.44% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #9257      +/-   ##
==========================================
- Coverage   91.31%   90.97%   -0.34%     
==========================================
  Files         357      353       -4     
  Lines       19202    18748     -454     
==========================================
- Hits        17534    17056     -478     
- Misses       1340     1364      +24     
  Partials      328      328              

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

@ycombinator ycombinator force-pushed the validate-pipeline-types branch from 8b5979d to be6c277 Compare February 12, 2024 23:24
@ycombinator
Copy link
Contributor Author

Hi @bogdandrutu, would you mind kicking off the CI checks again on this PR, please? Thanks!

@ycombinator
Copy link
Contributor Author

ycombinator commented Feb 13, 2024

Thanks @atoulme, for kicking off CI again. I've fixed another linter error (from impi) in 8b53d4e. Would you mind kicking off CI one more time, please? Thank you.

BTW, I noticed that CI, specifically the contrib-tests / contrib-tests-matrix (receiver-1) (pull_request) check, is failing on these tests from opentelemetry-collector-contrib:

--- FAIL: TestScrape (0.06s)
    --- FAIL: TestScrape/Standard (0.01s)
        network_scraper_test.go:234: 
            	Error Trace:	/tmp/opentelemetry-collector-contrib/receiver/hostmetricsreceiver/internal/scraper/networkscraper/network_scraper_test.go:234
            	            				/tmp/opentelemetry-collector-contrib/receiver/hostmetricsreceiver/internal/scraper/networkscraper/network_scraper_test.go:203
            	Error:      	Not equal: 
            	            	expected: 12
            	            	actual  : 13
            	Test:       	TestScrape/Standard
    --- FAIL: TestScrape/Standard_with_direction_removed (0.01s)
        network_scraper_test.go:234: 
            	Error Trace:	/tmp/opentelemetry-collector-contrib/receiver/hostmetricsreceiver/internal/scraper/networkscraper/network_scraper_test.go:234
            	            				/tmp/opentelemetry-collector-contrib/receiver/hostmetricsreceiver/internal/scraper/networkscraper/network_scraper_test.go:203
            	Error:      	Not equal: 
            	            	expected: 12
            	            	actual  : 13
            	Test:       	TestScrape/Standard_with_direction_removed
    --- FAIL: TestScrape/Validate_Start_Time (0.01s)
        network_scraper_test.go:234: 
            	Error Trace:	/tmp/opentelemetry-collector-contrib/receiver/hostmetricsreceiver/internal/scraper/networkscraper/network_scraper_test.go:234
            	            				/tmp/opentelemetry-collector-contrib/receiver/hostmetricsreceiver/internal/scraper/networkscraper/network_scraper_test.go:203
            	Error:      	Not equal: 
            	            	expected: 12
            	            	actual  : 13
            	Test:       	TestScrape/Validate_Start_Time
    --- FAIL: TestScrape/Include_Filter_that_matches_nothing (0.01s)
        network_scraper_test.go:234: 
            	Error Trace:	/tmp/opentelemetry-collector-contrib/receiver/hostmetricsreceiver/internal/scraper/networkscraper/network_scraper_test.go:234
            	            				/tmp/opentelemetry-collector-contrib/receiver/hostmetricsreceiver/internal/scraper/networkscraper/network_scraper_test.go:203
            	Error:      	Not equal: 
            	            	expected: 12
            	            	actual  : 13
            	Test:       	TestScrape/Include_Filter_that_matches_nothing
    --- FAIL: TestScrape/Conntrack_error_ignored_if_metric_disabled (0.01s)
        network_scraper_test.go:234: 
            	Error Trace:	/tmp/opentelemetry-collector-contrib/receiver/hostmetricsreceiver/internal/scraper/networkscraper/network_scraper_test.go:234
            	            				/tmp/opentelemetry-collector-contrib/receiver/hostmetricsreceiver/internal/scraper/networkscraper/network_scraper_test.go:203
            	Error:      	Not equal: 
            	            	expected: 12
            	            	actual  : 13
            	Test:       	TestScrape/Conntrack_error_ignored_if_metric_disabled
FAIL
FAIL	github.com/open-telemetry/opentelemetry-collector-contrib/receiver/hostmetricsreceiver/internal/scraper/networkscraper	0.081s

I'm not following how the failing assertion in a test for the hostmetricsreceiver component might be failing because of the change in this PR here. 🤔

@atoulme
Copy link
Contributor

atoulme commented Feb 13, 2024

It's possible contrib CI is broken. Rerunning.

@ycombinator
Copy link
Contributor Author

ycombinator commented Feb 13, 2024

It's possible contrib CI is broken. Rerunning.

Thanks. Or could it be because I'm not a OTel Community member (yet)?

[EDIT] Never mind, I misunderstood what you meant by "contrib CI". I understand now that you were referring to the failing tests, not the fact that you have to manually trigger CI runs for me on this PR.

@atoulme
Copy link
Contributor

atoulme commented Feb 13, 2024

Nothing like that, we just run CI by checking out the latest main of contrib, which can break.

FWIW CI doesn't run for you on commit because this is your first PR. After you have a commit in the repository, CI will run when you push to your branch without our intervention.

Copy link
Contributor

This PR was marked stale due to lack of activity. It will be closed in 14 days.

@github-actions github-actions bot added Stale and removed Stale labels Feb 27, 2024
@ycombinator
Copy link
Contributor Author

Hi @atoulme, could you please guide me on what's needed to merge this PR? I'm afraid it will be closed in 14 days otherwise due to being stale. Thanks!

@atoulme
Copy link
Contributor

atoulme commented Feb 28, 2024

Hi @atoulme, could you please guide me on what's needed to merge this PR? I'm afraid it will be closed in 14 days otherwise due to being stale. Thanks!

you ask for review by pinging approvers. I'm not an approver. You can participate in the SIG meeting as well, which is happening right now, to ask for review.

@ycombinator ycombinator force-pushed the validate-pipeline-types branch from 972934d to 382fcae Compare April 9, 2024 06:05
@ycombinator
Copy link
Contributor Author

@codeboten @bogdandrutu @dmitryax @mx-psi Would one of you have some time to review this PR and merge it if it's ready, please? It's been open for nearly three months now. Thank you!

Copy link
Member

@mx-psi mx-psi left a comment

Choose a reason for hiding this comment

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

Thanks, merging!

@mx-psi mx-psi merged commit de3ef01 into open-telemetry:main Apr 10, 2024
46 of 47 checks passed
@github-actions github-actions bot added this to the next release milestone Apr 10, 2024
@ycombinator ycombinator deleted the validate-pipeline-types branch April 10, 2024 14:07
bogdandrutu pushed a commit that referenced this pull request May 3, 2024
#### Description

This PR reverts the change made in
#9257 due
to problems reported in
#10031.

<!-- Issue number if applicable -->
#### Link to tracking issue
Fixes #10031.
andrzej-stencel pushed a commit to andrzej-stencel/opentelemetry-collector that referenced this pull request May 27, 2024
#### Description

This PR reverts the change made in
open-telemetry#9257 due
to problems reported in
open-telemetry#10031.

<!-- Issue number if applicable -->
#### Link to tracking issue
Fixes open-telemetry#10031.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

validate command does not validate pipeline type
5 participants