[exporter/otlphttpexporter] Use NewDefaultClientConfig instead of manually creating struct #11273
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ually creating struct This PR makes usage of `NewDefaultClientConfig` instead of manually creating the confighttp.ClientConfig struct. The updates to defaults are maintained (Timeout, Compression, WriteBufferSize) whereas the fields that match the default are not manually set anymore (Endpoint, Headers). Issue: open-telemetry#9478 (comment)
songy23
approved these changes
Sep 25, 2024
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #11273 +/- ##
=======================================
Coverage 91.42% 91.42%
=======================================
Files 424 424
Lines 20188 20190 +2
=======================================
+ Hits 18456 18458 +2
Misses 1348 1348
Partials 384 384 ☔ View full report in Codecov by Sentry. |
1 task
|
@bogdandrutu This relates to the second point in: #9478 (comment). We are going to change the pointer fields in the ClientConfig (potentially through approach in #10260). The reasoning is that it will then be easier to update these fields once all instances are using NewDefaultClientConfig instead of creating the struct manually. I listed all places where the struct is created manually here: #11274. That said, if we go with the optional.Optional approach, we will still need to update the fields that I unset manually here. I added a question at the end of #11274 on how we want to treat fields that are set in the default but currently unset in components. |
bogdandrutu
approved these changes
Sep 26, 2024
mackjmr
added a commit
to mackjmr/opentelemetry-collector
that referenced
this pull request
Sep 30, 2024
…ult client config This is a follow up to open-telemetry#11273. Although I set fields MaxIdleConns, MaxIdleConnsPerHost, MaxConnsPerHost, IdleConnTimeout to nil manually to keep backwards compatibility, it turns out that in the call to [ToClient](https://github.com/open-telemetry/opentelemetry-collector/blob/main/config/confighttp/confighttp.go#L141-L166) the http.Transport defaults are used. Thus, not setting to nil will maintain the same behaviour and is not necessary.
bogdandrutu
pushed a commit
that referenced
this pull request
Oct 2, 2024
…ult client config (#11299) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description This is a follow up to #11273 in which I had set fields `MaxIdleConns`, `MaxIdleConnsPerHost`, `MaxConnsPerHost`, `IdleConnTimeout` to nil manually to keep backwards compatibility. However, in the call to [ToClient](https://github.com/open-telemetry/opentelemetry-collector/blob/main/config/confighttp/confighttp.go#L141-L166) the `http.Transport` defaults are used. The call to `NewDefaultClientConfig` also uses the `http.Transport` defaults. Thus, not setting to nil will maintain the same behaviour/ is unnecessary. <!-- Issue number if applicable --> #### Link to tracking issue Fixes # <!--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.-->
jackgopack4
pushed a commit
to jackgopack4/opentelemetry-collector
that referenced
this pull request
Oct 8, 2024
…ually creating struct (open-telemetry#11273) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description This PR makes usage of `NewDefaultClientConfig` instead of manually creating the `confighttp.ClientConfig` struct. The updates to defaults are maintained (Timeout, Compression, WriteBufferSize) whereas the fields that match the default are not manually set anymore (Endpoint, Headers). It also sets to nil the fields that are set in default but weren't set previously (MaxIdleConns, MaxIdleConnsPerHost, MaxConnsPerHost, IdleConnTimeout) to retain the same behaviour. I am on the fence about this one, should we switch to using the defaults ? <!-- Issue number if applicable --> #### Link to tracking issue open-telemetry#11274 <!--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.-->
jackgopack4
pushed a commit
to jackgopack4/opentelemetry-collector
that referenced
this pull request
Oct 8, 2024
…ult client config (open-telemetry#11299) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description This is a follow up to open-telemetry#11273 in which I had set fields `MaxIdleConns`, `MaxIdleConnsPerHost`, `MaxConnsPerHost`, `IdleConnTimeout` to nil manually to keep backwards compatibility. However, in the call to [ToClient](https://github.com/open-telemetry/opentelemetry-collector/blob/main/config/confighttp/confighttp.go#L141-L166) the `http.Transport` defaults are used. The call to `NewDefaultClientConfig` also uses the `http.Transport` defaults. Thus, not setting to nil will maintain the same behaviour/ is unnecessary. <!-- Issue number if applicable --> #### Link to tracking issue Fixes # <!--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.-->
djaglowski
pushed a commit
to open-telemetry/opentelemetry-collector-contrib
that referenced
this pull request
Oct 9, 2024
…ing struct (#35452) **Description:** <Describe what has changed.> <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> Similar to open-telemetry/opentelemetry-collector#11273. This PR makes usage of the `NewDefaultClientConfig` instead of manually creating the `confighttp.ClientConfig` struct as part of #35457. **Link to tracking Issue:** <Issue number if applicable> #35457 **Testing:** <Describe what testing was performed and which tests were added.> **Documentation:** <Describe the documentation added.> --------- Signed-off-by: ChrsMark <chrismarkou92@gmail.com>
jmichalek132
pushed a commit
to jmichalek132/opentelemetry-collector-contrib
that referenced
this pull request
Oct 10, 2024
…ing struct (open-telemetry#35452) **Description:** <Describe what has changed.> <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> Similar to open-telemetry/opentelemetry-collector#11273. This PR makes usage of the `NewDefaultClientConfig` instead of manually creating the `confighttp.ClientConfig` struct as part of open-telemetry#35457. **Link to tracking Issue:** <Issue number if applicable> open-telemetry#35457 **Testing:** <Describe what testing was performed and which tests were added.> **Documentation:** <Describe the documentation added.> --------- Signed-off-by: ChrsMark <chrismarkou92@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR makes usage of
NewDefaultClientConfiginstead of manually creating theconfighttp.ClientConfigstruct. The updates to defaults are maintained (Timeout, Compression, WriteBufferSize) whereas the fields that match the default are not manually set anymore (Endpoint, Headers).It also sets to nil the fields that are set in default but weren't set previously (MaxIdleConns, MaxIdleConnsPerHost, MaxConnsPerHost, IdleConnTimeout) to retain the same behaviour. I am on the fence about this one, should we switch to using the defaults ?
Link to tracking issue
#11274
Testing
Documentation