-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Clearly separate Config and Settings terms used in struct names throughout the codebase #6767
Comments
I think we should start working on this, because we cannot delay until the stability. |
**Description:** Removes deprecated items from `confighttp` **Link to tracking Issue:** Related to #6767
Removing from the confighttp milestone as the public structs now use |
Closing this in favour of #9428 |
exporterhelper still needs updating |
We still need to update:
|
I'll work on this. |
#### Description This PR renames `TimeoutSettings` and `QueueSettings` (as well as the corresponding `NewDefault` functions) to `TimeoutConfig` and `QueueConfig`, for naming consistency reasons. The previous struct/function names are kept as deprecated aliases of the new ones for now. #### Link to tracking issue Updates #6767 (edit: reworded by @mx-psi) #### Testing No behavior changes were made, so no additional testing should be necessary. The references to the aforementioned structs/functions in existing tests have been renamed as well. This means the deprecated function aliases are not tested, lowering the coverage a bit. #### Documentation The new functions are documented identically to the previous ones.
…tings (#35158) **Description:** `TimeoutSettings` and `QueueSettings` in the `exporterhelper` core collector package were renamed to `TimeoutConfig` and `QueueConfig` for naming consistency reasons, and the related `NewDefault` functions were renamed as well. This PR updates the core libraries to a prerelease version with those changes, and updates opentelemetry-collector-contrib modules to the new names, to plan for the deprecation of the old names in v0.110.0. **Link to tracking Issue:** Related to [this PR](open-telemetry/opentelemetry-collector#11132) and [this issue](open-telemetry/opentelemetry-collector#6767) on the core collector. **Notes:** - `go.opentelemetry.io/collector/cmd/mdatagen` is specifically *not* updated, as it currently has a bug causing a CI test failure. - The `prometheus-compliance-tests` CI failure is unrelated to this PR.
…11178) #### Description My PR #11132 introduced a small breaking change in the API of `otlpexporter`, which I failed to notice at the time. This PR adds a release note about this. Specifically, the `TimeoutSettings` field in `otlpexporter.Config` was renamed to `TimeoutConfig` ([link to the new code](https://github.com/jade-guiton-dd/opentelemetry-collector/blob/543c4f510d3bbcd50e914f4e5d7f22c5fcbda92d/exporter/otlpexporter/config.go#L23)). As this is an embedded field, renaming the type of the field renamed the field itself. (Another option would have been to de-embed the field, and keep the old name. This has less potential for breakage, but would technically also be a breaking change.) #### Link to tracking issue Indirectly related to #6767
If I'm not mistaken, #11264 was the last step for this issue, so it can probably be closed. |
Taking a look at the output of |
…tings (open-telemetry#35158) **Description:** `TimeoutSettings` and `QueueSettings` in the `exporterhelper` core collector package were renamed to `TimeoutConfig` and `QueueConfig` for naming consistency reasons, and the related `NewDefault` functions were renamed as well. This PR updates the core libraries to a prerelease version with those changes, and updates opentelemetry-collector-contrib modules to the new names, to plan for the deprecation of the old names in v0.110.0. **Link to tracking Issue:** Related to [this PR](open-telemetry/opentelemetry-collector#11132) and [this issue](open-telemetry/opentelemetry-collector#6767) on the core collector. **Notes:** - `go.opentelemetry.io/collector/cmd/mdatagen` is specifically *not* updated, as it currently has a bug causing a CI test failure. - The `prometheus-compliance-tests` CI failure is unrelated to this PR.
…pen-telemetry#11264) #### Description Follow-up to open-telemetry#11132 now that 0.110 has been released. #### Link to tracking issue Should be the final step for open-telemetry#6767.
…n coding guidelines (#11549) <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> #### Description <!-- Issue number if applicable --> Reflects existing practice in coding guidelines. #### Link to tracking issue Relates to #6767, fixes #9428
…tings (#35158) **Description:** `TimeoutSettings` and `QueueSettings` in the `exporterhelper` core collector package were renamed to `TimeoutConfig` and `QueueConfig` for naming consistency reasons, and the related `NewDefault` functions were renamed as well. This PR updates the core libraries to a prerelease version with those changes, and updates opentelemetry-collector-contrib modules to the new names, to plan for the deprecation of the old names in v0.110.0. **Link to tracking Issue:** Related to [this PR](open-telemetry/opentelemetry-collector#11132) and [this issue](open-telemetry/opentelemetry-collector#6767) on the core collector. **Notes:** - `go.opentelemetry.io/collector/cmd/mdatagen` is specifically *not* updated, as it currently has a bug causing a CI test failure. - The `prometheus-compliance-tests` CI failure is unrelated to this PR.
Currently, we use the
Config
term for collector configuration as a whole and parts of it defined for receivers/processors/exporters/extensions. Examples:otelcol.Config
component.Config
otlpexporter.Config
But for unmarshalling some deeper parts of the user config, we use
Settings
structs, for example:exporterhelper.QueueSettings
configgrpc.GRPCClientSettings
configtls.TLSSetting
At the same time
service/telemetry
package still usesConfig
, e.g.MetricsConfig
,LogsSamplingConfig
, andTracesConfig
.The suggestion is to use
Config
term for all the structs used to unmarshal any parts of the YAML config provided by users. We will keepSettings
only for structs that are populated programmatically, like:component.TelemetrySettings
component.ReceiverSettings
The text was updated successfully, but these errors were encountered: