Add RFC: Instrumentation v1beta1#5079
Conversation
Signed-off-by: Pavol Loffay <p.loffay@gmail.com>
swiatekm
left a comment
swiatekm
left a comment
There was a problem hiding this comment.
Looks good to me overall. I have a major question involving the annotation -> label change, and some minor ones.
|
|
||
| ## Non-Goals (for initial v1beta1) | ||
|
|
||
| * Label selectors for targeting workloads ([#2744](https://github.com/open-telemetry/opentelemetry-operator/issues/2744), [#821](https://github.com/open-telemetry/opentelemetry-operator/issues/821)) - additive feature, can be added later without breaking changes |
There was a problem hiding this comment.
I think this is a breaking change in a practical sense. The whole point of it is that we want to scope the mutating webhook by label. We can only do that if we are confident users are using the label to indicate instrumented resources, rather than the annotation. It's a breaking change to our public API, though not to the CRD.
| - **`spec.declarativeConfig`** — strongly-typed Go structs matching the [OTel SDK configuration schema](https://github.com/open-telemetry/opentelemetry-configuration). The operator serializes this to a YAML file, mounts it into the workload, and sets `OTEL_CONFIG_FILE`. | ||
| - **`spec.envConfig`** — the existing env-var-based configuration (`exporter`, `sampler`, `propagators`, `resource`), moved under a dedicated field. This preserves the current v1alpha1 behavior. | ||
|
|
||
| Setting both `declarativeConfig` and `envConfig` is invalid and rejected by the webhook. |
There was a problem hiding this comment.
How do we handle differences in SDK support for the declarative configuration? I think we need to keep a list of supported languages, probably overridable through config for easier testing. How will we update this list?
There was a problem hiding this comment.
The SDK support is documented here https://github.com/open-telemetry/opentelemetry-configuration/blob/main/language-support-status.md
The language support is even more complicated because it's split per config feature. Given the large number of features I am not sure what validation we can perform in the operator.
I have added a section with supported languages. Only .net does not support it at all.
|
|
||
| ## Migration Strategy | ||
|
|
||
| 1. **Conversion webhook**: Implement a conversion webhook that translates between v1alpha1 and v1beta1, handling field renames and removals automatically. |
There was a problem hiding this comment.
Let's be sure to make this optional. It was a massive pain to rely on it for backwards compatibility during the Collector CR migration. The way I imagine this is that supporting v1alpha1 will involve internally converting to v1beta1, and the conversion webhook will simply use the same method.
There was a problem hiding this comment.
Do you mean to make the conversion webhook optional?
pavolloffay
added
the
Skip Changelog
Signed-off-by: Pavol Loffay <p.loffay@gmail.com>
2 participants
Description:
This PR adds RFC for Instrumenation v1beta1
Link to tracking Issue(s):
Related to #5060
Testing:
Documentation: