Component(s)
auto-instrumentation
Is your feature request related to a problem? Please describe.
Follow to this slack conversation.
Right now the version of language instrumentations is optional. This couples operator version scheme to the collective version scheme of all the language instrumentations it supports.
We saw this when the opentelemetry java agent went to 2.x and there was a long delay in upgrading the version of the java instrumentation image to 2.x. Doing so meant updating the default, which meant exposing users to those breaking changes who rely on the default.
The OpenTelemetry project has a goal of instrumentations to be stable by default. That means marking things as 1.x rather then the defacto stable 0.x we've been going with. Maintainers will only feel comfortable marking things 1.x if there is an allowance to have a 2.x. And so we need to expect regular major version bumps from instrumentation packages, which will include breaking changes.
The plan is to release opentelemetry java agent 3.x next month. And 4.x will come probably sometime 12-24 months after that. Other languages will likely follow suit since opentelemetry java agent's release pattern of regular major version updates with support for LATEST_MAJOR_VERSION - 1 is being touted as a pattern for other languages to follow.
The operator doesn't want to be in the business of cutting a new major version for each new major version of any instrumentation. And it doesn't want to be in the business of holding users back from using the latest versions of instrumentations while it figures out when its appropriate to update the new default to the next major version.
Describe the solution you'd like
The only solution I can think of is to force users to specify the version of instrumentations in their instrumentation CRs.
Proposal:
- Update the Instrumentation CRD to require users specify the version of language instrumentations
- Setup automation to update and publish new instrumentation images for each and every release of respective language instrumentation. No curation decisions. The images are just a repackaging of the instrumentations, with lockstep versioning schemes.
- Any snippets in the README or elsewhere in the repo to help users get started should have the latest language instrumentation versions included, such that users can simply copy and paste the CR.
- Setup the language instrumentation version update process to automatically update the versions referenced in these snippets.
With this, operator can publish updates with a versioning scheme independent of language instrumentation releases. Users can confidently update their operator version without any impact to the schema of the telemetry produced by instrumentation. The UX impact of these required fields in minimal because nobody writes CRs from scratch - everyone copy / pastes from the examples in github, which now just have a few extra lines.
Describe alternatives you've considered
No response
Additional context
No response
Tip
No response
Component(s)
auto-instrumentation
Is your feature request related to a problem? Please describe.
Follow to this slack conversation.
Right now the version of language instrumentations is optional. This couples operator version scheme to the collective version scheme of all the language instrumentations it supports.
We saw this when the opentelemetry java agent went to 2.x and there was a long delay in upgrading the version of the java instrumentation image to 2.x. Doing so meant updating the default, which meant exposing users to those breaking changes who rely on the default.
The OpenTelemetry project has a goal of instrumentations to be stable by default. That means marking things as 1.x rather then the defacto stable 0.x we've been going with. Maintainers will only feel comfortable marking things 1.x if there is an allowance to have a 2.x. And so we need to expect regular major version bumps from instrumentation packages, which will include breaking changes.
The plan is to release opentelemetry java agent 3.x next month. And 4.x will come probably sometime 12-24 months after that. Other languages will likely follow suit since opentelemetry java agent's release pattern of regular major version updates with support for
LATEST_MAJOR_VERSION - 1is being touted as a pattern for other languages to follow.The operator doesn't want to be in the business of cutting a new major version for each new major version of any instrumentation. And it doesn't want to be in the business of holding users back from using the latest versions of instrumentations while it figures out when its appropriate to update the new default to the next major version.
Describe the solution you'd like
The only solution I can think of is to force users to specify the version of instrumentations in their instrumentation CRs.
Proposal:
With this, operator can publish updates with a versioning scheme independent of language instrumentation releases. Users can confidently update their operator version without any impact to the schema of the telemetry produced by instrumentation. The UX impact of these required fields in minimal because nobody writes CRs from scratch - everyone copy / pastes from the examples in github, which now just have a few extra lines.
Describe alternatives you've considered
No response
Additional context
No response
Tip
No response