The Instrumentation v1beta1 document has an objective to support declarative config. This is great!
Support strongly-typed declarative configuration
The "strongly-typed" bit is going to take some careful planning, since the schema allows for experimental properties / types which can have breaking changes in minor versions: https://github.com/open-telemetry/opentelemetry-configuration/blob/main/VERSIONING.md#experimental-features That means the operator's strong types need to make considerations for this, and not over promise for experimental types / properties.
The alternative is to represent it as a generic type like map[string]any.
If you go with strongly typed, you probably need something to keep those types up to date with the schema. In my experience, there's too much config schema surface area to reasonably maintain types by hand. Maybe that's a problem already solved.
Next, the document uses this example:
apiVersion: opentelemetry.io/v1beta1
kind: Instrumentation
metadata:
name: declarative-example
spec:
declarativeConfig:
file_format: "0.4"
resource:
attributes:
- name: service.namespace
value: production
tracer_provider:
sampler:
parent_based:
root:
trace_id_ratio_based:
ratio: 0.25
processors:
- batch: {}
exporters:
- otlp:
endpoint: http://collector:4318
protocol: http/protobuf
0.4 is quite old at this point (published 3/2025). The latest release is 1.1.0.
On batch: {}. First, a minor point: this is invalid since exporter is a required property.
More importantly, I think the inclusion of {} to represent an empty object is a function of the serialization library / config used by k8s. In declarative config, we have all sorts of snippets and examples that omit the curly braces on empty objects (example). When I was prototyping an operator that supported declarative config, I think I found a way around this. I forget the details, but I encourage you to try to avoid this requirement to include {}, since doing so will mean that many valid snippets will have to be modified to work with the operator.
The Instrumentation v1beta1 document has an objective to support declarative config. This is great!
The "strongly-typed" bit is going to take some careful planning, since the schema allows for experimental properties / types which can have breaking changes in minor versions: https://github.com/open-telemetry/opentelemetry-configuration/blob/main/VERSIONING.md#experimental-features That means the operator's strong types need to make considerations for this, and not over promise for experimental types / properties.
The alternative is to represent it as a generic type like
map[string]any.If you go with strongly typed, you probably need something to keep those types up to date with the schema. In my experience, there's too much config schema surface area to reasonably maintain types by hand. Maybe that's a problem already solved.
Next, the document uses this example:
0.4 is quite old at this point (published 3/2025). The latest release is 1.1.0.
On
batch: {}. First, a minor point: this is invalid since exporter is a required property.More importantly, I think the inclusion of
{}to represent an empty object is a function of the serialization library / config used by k8s. In declarative config, we have all sorts of snippets and examples that omit the curly braces on empty objects (example). When I was prototyping an operator that supported declarative config, I think I found a way around this. I forget the details, but I encourage you to try to avoid this requirement to include{}, since doing so will mean that many valid snippets will have to be modified to work with the operator.