-
Notifications
You must be signed in to change notification settings - Fork 23
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
docs: Custom OTTL with OpenTelemetry-based Telemetry Pipelines #1520
base: main
Are you sure you want to change the base?
Conversation
docs/contributor/arch/015-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
docs/contributor/arch/015-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
docs/contributor/arch/015-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
docs/contributor/arch/015-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
docs/contributor/arch/015-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
docs/contributor/arch/015-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
docs/contributor/arch/015-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
docs/contributor/arch/015-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Nina Hingerl <[email protected]>
docs/contributor/arch/016-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
…ry-pipelines.md Co-authored-by: Korbinian Stoemmer <[email protected]>
docs/contributor/arch/016-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
…ry-pipelines.md Co-authored-by: Korbinian Stoemmer <[email protected]>
docs/contributor/arch/016-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
…ry-pipelines.md Co-authored-by: Korbinian Stoemmer <[email protected]>
docs/contributor/arch/016-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
docs/contributor/arch/016-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
docs/contributor/arch/016-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
docs/contributor/arch/016-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
docs/contributor/arch/016-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
docs/contributor/arch/016-transform-filter-support-for-telemetry-pipelines.md
Outdated
Show resolved
Hide resolved
|
||
To mitigate this risk, we suggest the following measures: | ||
- The [beta version](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/28892) of the OTTL library will be used in the OTel Collector to ensure that the library is stable and reliable. | ||
- New Versions with Breaking Changes: New versions with [breaking changes](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/coding-guidelines.md#breaking-changes) of the OTTL library will be rolled out with backward compatibility. This will help users adapt changes and reduce the chance of widespread disruption. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this a measure we can take? Do we make sure that new versions are rolled out with backward compatibility? The passive phrase "will be rolled out" doesn't indicate who takes care of that; or what our contribution to this mitigative action is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The point reworked
- Thorough Testing: We will maintain strict version control of the OTTL library, ensuring that each update is thoroughly tested. Automated tests will validate that existing pipelines continue to work as expected. | ||
- Documentation: We will provide detailed documentation and practical examples of how to configure filter and transformation processors using OTTL expressions. | ||
- Community Support: We will actively engage with the OpenTelemetry community to address any issues or concerns that arise from using the OTTL library. | ||
- The public Go API: The breaking changes most likely will not follow deprecation policy, this may require changes in our implementation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- The public Go API: The breaking changes most likely will not follow deprecation policy, this may require changes in our implementation. | |
- The public Go API: The breaking changes most likely will not follow deprecation policy. This may require changes in our implementation. |
Not sure how this is a mitigation measure; it's just a statement. Why will the breaking changes (the ones from line 114, I assume?) not follow (which?) deprecation strategy? Which specific mitigative action does this require? Something like "We must design our implementation to cope with that." or "We must continuously monitor this and change our implementation accordingly"? or something similar?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed this point from the mitigation, this is more an exception to mention
Co-authored-by: Nina Hingerl <[email protected]>
|
||
To mitigate this risk, we suggest the following measures: | ||
- The [beta version](https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/28892) of the OTTL library will be used in the OTel Collector to ensure that the library is stable and reliable. | ||
- New Versions with Breaking Changes: The [breaking changes](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/coding-guidelines.md#breaking-changes) of the OTTL library will be released with backward compatibility, the backward compatibility provided via `feature gates` and will be available over several releases. This will help users adapt changes and reduce the chance of widespread disruption. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a measure we can take? Do we make sure that new versions are released with backward compatibility? The passive phrase "will be released" doesn't indicate who takes care of that; or what our contribution to this mitigative action is. Or, coming to the intro sentence, do we suggest this to the OTel team? Are we asking them to make sure their releases are backward compatible?
I see you changed this paragraph but it's still all passive voice, and it's not clear to me who's taking care of this mitigation measure.
- Community Support: We will actively engage with the OpenTelemetry community to address any issues or concerns that arise from using the OTTL library. | ||
|
||
|
||
> **NOTE:** The public Go API (not the user faced features), the breaking changes most likely will not follow deprecation policy, this may require changes in our implementation uses the public API. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see you formatted this now as a note, not a bullet point. Still, it's not clear to me how this affects our implementation, my previous questions still stand.
Description
Changes proposed in this pull request (what was done and why):
Changes refer to particular issues, PRs or documents:
Traceability
Related Issues
section.