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.

Sign up for GitHub

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

Add OTLP Exporting support matrix #2524

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from
Draft

Add OTLP Exporting support matrix #2524

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 39 additions & 0 deletions opentelemetry-otlp/tests/integration_test/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,3 +15,42 @@ popped back out into the files output by the collector.
* Docker, for the test container
* TCP/4317 and TCP/4318 free on your local machine. If you are running another
collector, you'll need to stop it for the tests to run.

## Test Matrix

Copy link
Contributor

Choose a reason for hiding this comment

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

Should we add:

Suggested change
We aim to support and provide integration test coverage for every permutation of [A/B/C]

... or something along these lines, so its clear what the desired state here is? It'd be helpful to identify gaps. I think optimally we'd link out to some architectural or design goal elsewhere, if we had one handy.

| **Exporter Type** | **Provider Creation** | **Logging** | **Network Clients** | **Status** |
Copy link
Contributor

Choose a reason for hiding this comment

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

I find it difficult to parse the table for "exhaustiveness". It might be easier if we break it down along some other axis into multiple tables.

Perhaps by network client - as then we'll get 4 tables of 8 rows?

|----------------------|---------------------------|------------------------|----------------------------|------------|
| **Simple** | Inside `tokio::Runtime` | Inside `tokio::Runtime` | `tonic` | Works |
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: It would be nice to use check marks here similar to the test matrix for metrics: https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-sdk/src/metrics/test.md

image

Suggested change
| **Simple** | Inside `tokio::Runtime` | Inside `tokio::Runtime` | `tonic` | Works |
| **Simple** | Inside `tokio::Runtime` | Inside `tokio::Runtime` | `tonic` | :white_check_mark: |

| **Simple** | Inside `tokio::Runtime` | Inside `tokio::Runtime` | `reqwest` | Works |
| **Simple** | Inside `tokio::Runtime` | Inside `tokio::Runtime` | `reqwest-blocking` | Works |
| **Simple** | Inside `tokio::Runtime` | Inside `tokio::Runtime` | `hyper` | Works |
| **Simple** | Inside `tokio::Runtime` | Outside `tokio::Runtime` | `tonic` | Works |
| **Simple** | Inside `tokio::Runtime` | Outside `tokio::Runtime` | `reqwest` | Works |
| **Simple** | Inside `tokio::Runtime` | Outside `tokio::Runtime` | `reqwest-blocking` | Works |
| **Simple** | Inside `tokio::Runtime` | Outside `tokio::Runtime` | `hyper` | Works |
| **Simple** | Outside `tokio::Runtime` | Inside `tokio::Runtime` | `tonic` | Works |
| **Simple** | Outside `tokio::Runtime` | Inside `tokio::Runtime` | `reqwest` | Works |
| **Simple** | Outside `tokio::Runtime` | Inside `tokio::Runtime` | `reqwest-blocking` | Works |
| **Simple** | Outside `tokio::Runtime` | Inside `tokio::Runtime` | `hyper` | Works |
| **Simple** | Outside `tokio::Runtime` | Outside `tokio::Runtime` | `tonic` | Works |
| **Simple** | Outside `tokio::Runtime` | Outside `tokio::Runtime` | `reqwest` | Works |
| **Simple** | Outside `tokio::Runtime` | Outside `tokio::Runtime` | `reqwest-blocking` | Works |
| **Simple** | Outside `tokio::Runtime` | Outside `tokio::Runtime` | `hyper` | Works |
| **Batch** | Inside `tokio::Runtime` | Inside `tokio::Runtime` | `tonic` | Works |
| **Batch** | Inside `tokio::Runtime` | Inside `tokio::Runtime` | `reqwest` | Works |
| **Batch** | Inside `tokio::Runtime` | Inside `tokio::Runtime` | `reqwest-blocking` | Works |
| **Batch** | Inside `tokio::Runtime` | Inside `tokio::Runtime` | `hyper` | Works |
| **Batch** | Inside `tokio::Runtime` | Outside `tokio::Runtime` | `tonic` | Works |
| **Batch** | Inside `tokio::Runtime` | Outside `tokio::Runtime` | `reqwest` | Works |
| **Batch** | Inside `tokio::Runtime` | Outside `tokio::Runtime` | `reqwest-blocking` | Works |
| **Batch** | Inside `tokio::Runtime` | Outside `tokio::Runtime` | `hyper` | Works |
| **Batch** | Outside `tokio::Runtime` | Inside `tokio::Runtime` | `tonic` | Works |
| **Batch** | Outside `tokio::Runtime` | Inside `tokio::Runtime` | `reqwest` | Works |
| **Batch** | Outside `tokio::Runtime` | Inside `tokio::Runtime` | `reqwest-blocking` | Works |
| **Batch** | Outside `tokio::Runtime` | Inside `tokio::Runtime` | `hyper` | Works |
| **Batch** | Outside `tokio::Runtime` | Outside `tokio::Runtime` | `tonic` | Works |
| **Batch** | Outside `tokio::Runtime` | Outside `tokio::Runtime` | `reqwest` | Works |
| **Batch** | Outside `tokio::Runtime` | Outside `tokio::Runtime` | `reqwest-blocking` | Works |
| **Batch** | Outside `tokio::Runtime` | Outside `tokio::Runtime` | `hyper` | Works |

Copy link
Contributor

Choose a reason for hiding this comment

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

This is not really related to the PR at hand, but I also remain unconvinced that we are gaining much by supporting hyper/tonic/reqwest all at once; we started discussing this elsewhere (but I can't find the PR anymore). I struggle to find a strong need for anything more than a single client for async and sync calling, as it is 1/ an implementation detail that does not concern the caller and 2/ likely won't save space in the app anyway because of the way rust manages dep resolution.

Copy link
Member Author

Choose a reason for hiding this comment

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

Similar to async part, Rust does not have a std library for making Http calls or asynchronous runtimes... So we need to provide some ability for users to bring-their-own, and provide a default implementation for at least 1 common one.


Loading