-
Notifications
You must be signed in to change notification settings - Fork 932
Description
TL;DR; It’s unclear whether omitted fields in declarative configuration should use SDK defaults or configuration-defined defaults. This ambiguity leads to inconsistent behavior across languages (e.g., OTLP exporter protocol defaults differ).
While reading the declarative configuration SDK specification, I’ve run into difficulty understanding what the default values should be when a field is omitted. Specifically:
- Should the omitted field take on the SDK’s built-in default, or
- Should it use a configuration-defined default?
The specification section here does not make this distinction clear:
opentelemetry-specification/specification/configuration/sdk.md
Lines 263 to 271 in 7295dc4
If a property has a default value defined (i.e. is _not_ required) and is | |
missing or present but null, Create MUST ensure the SDK component is configured | |
with the default value. If a property is required and is missing or present but | |
null, Create SHOULD return an error. For example, if configuring | |
the [span batching processor](../trace/sdk.md#batching-processor) and | |
the `scheduleDelayMillis` property is missing or present but null, the component | |
is configured with the default value of `5000`. However, if the `exporter` | |
property is missing or present but null, Create fails fast since there is no | |
default value for `exporter`. |
My assumption is that the defaults illustrated in this example are intended to apply:
https://github.com/open-telemetry/opentelemetry-configuration/blob/main/examples/sdk-migration-config.yaml
However, the specification doesn’t explicitly say so.
It’s also possible that the spec intends for SDK defaults to be used instead. If that’s the case, it could lead to inconsistencies, since SDK defaults may differ between languages. For example, the OTLP exporter’s default protocol is grpc
in some SDKs and http/protobuf
in others. Such discrepancies could be confusing for end users.
Additionally, default values could be explicitly defined in the JSON Schema using the default
annotation:
https://json-schema.org/understanding-json-schema/reference/annotations.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status