<!--Ex. Fixing a bug - Describe the bug and how this fixes the issue.
Ex. Adding a feature - Explain what this achieves.-->
#### Description
Based on the experience of this process going through once, I am
suggesting we make the following changes:
1. Require announcing the final comment period via a comment and on the
#otel-collector-dev channel.
2. Require that all conversations are resolved. Allow RFC author to
resolve any conversation, but require them to leave a comment explaining
why
<!-- Issue number if applicable -->
#### Link to tracking issue
Fixes#11737
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
This PR adds a RFC for normalized telemetry across all pipeline
components. See
https://github.com/open-telemetry/opentelemetry-collector/issues/11343
edit by @mx-psi:
- Announced on #otel-collector-dev on 2024-10-23:
https://cloud-native.slack.com/archives/C07CCCMRXBK/p1729705290741179
- Announced on the Collector SIG meeting from 2024-10-30
---------
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
Co-authored-by: Damien Mathieu <42@dmathieu.com>
Co-authored-by: William Dumont <william.dumont@grafana.com>
Co-authored-by: Evan Bradley <11745660+evan-bradley@users.noreply.github.com>
#### Description
Define RFC merge process in the `docs/rfc/README.md`. This is meant to
be a tool for making decisions about hard stuff :)
---------
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
Co-authored-by: Evan Bradley <11745660+evan-bradley@users.noreply.github.com>
#### Description
This is a stripped-down version of
https://github.com/open-telemetry/opentelemetry-collector/pull/10121
that eschews implementation details in favor of answering questions
about _what_ we want to achieve instead of how we will achieve it. A
section from that PR has been reproduced here to cover a few approaches
for future discussions.
<!--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 -->
- Adds new `expandedValue` struct that holds the original string
representation if available for values resolved from a provider.
- Removes any mention of `expandedValue` in the public API by adding a
`sanitize` step before returning any `Get`s or `ToStringMap`s.
- Adds new decoding hook that checks if the target field is of `string`
type and uses the string representation in that case.
#### Link to tracking issue
Fixes#10605, Fixes#10405, Fixes#10659
<!--Describe what testing was performed and which tests were added.-->
#### Testing
<!--Describe the documentation added.-->
This changes the behavior in some cases, I update the test cases.
#### Documentation
<!--Please delete paragraphs that you did not use before submitting.-->
| ENV value | ${ENV} before unification | ${ENV} in v0.105.0 (also
${env:ENV} before unification) | Value after this PR |
|----------------------------|----------------------------|---------------------------------------------------------|----------------------------|
| foo\nbar | foo\nbar | foo bar | foo\nbar |
| 1111:1111:1111:1111:1111:: | 1111:1111:1111:1111:1111:: | **Error** |
1111:1111:1111:1111:1111:: |
| "0123" | "0123" | 0123 | "0123" |
**Description:** Adds an RFC about how environment variable resolution
should work
**Link to tracking Issue:** Fixes#9515, relates to:
- #8215
- #8565
- #9162
- #9531
- #9532
---------
Co-authored-by: Alex Boten <223565+codeboten@users.noreply.github.com>
Co-authored-by: Evan Bradley <11745660+evan-bradley@users.noreply.github.com>
Pablo Baeyens
Daniel Jaglowski
Nathan Baulch
Tyler Helmuth
Evan Bradley
Damien Mathieu