Change various usages of minimum to exclusiveMinimum #151
Conversation
|
Status update: waiting to see how open-telemetry/opentelemetry-specification#4331 shakes out. Based on this conversation, it appears the preference is to interpret a timeout value of zero to mean indefinite. Although not idea if given a fresh start, its a reasonable conclusion to reach given diverging implementations. We have somewhat of a fresh start in declarative config, but are tied back to the env vars config schema via env var substitution. |
…y-configuration into review-minimum-usage
|
UPDATE (1/13/2025): Updated to reflect the state of things in Spec PR#4331 which now seems poised to merge. Differences from what I originally proposed:
Given these changes, I've cleared the approvals. Please take a look @open-telemetry/configuration-approvers. |
There was a problem hiding this comment.
LGTM, my only comment is editorial.
Lines like:
# Configure maximum allowed time (in milliseconds) to export data. Value must be non-negative. A value of 0 indicates indefinite.
are very long in the yaml file itself.
Could type_description.yaml break this into separate lines, by adding an empty line as delimiter ?
The default configuration in examples will be copied and pasted a lot when people will use this, so a reasonable max size for a line will make it easier to consume.
👍 yes I can do this |
Resolves #4283. * Adds new guidance indicates that for timeout variables, "implementations SHOULD interpret timeout values of zero as indefinite". * Clarifies range of acceptable values for `OTEL_ATTRIBUTE_*` / `OTEL_SPAN_ATTRIBUTE_*` / `OTEL_LOGRECORD_ATTRIBUTE_*`, `OTEL_BSP_MAX_QUEUE_SIZE`, `OTEL_BLRP_MAX_QUEUE_SIZE`. Related PR to `opentelemetry-configuration`: open-telemetry/opentelemetry-configuration#151 --------- Co-authored-by: Reiley Yang <[email protected]> Co-authored-by: Robert Pająk <[email protected]>
Related to open-telemetry/opentelemetry-specification#4283, but not blocked by the resolution over there.
With #142, the main principle of what constitutes an allowed change is whether it makes validation more or less restrictive. In reviewing our use of the JSON schema minimum keyword, which has inclusive semantics, I found a variety of areas which may come back to bite us. In all these cases, the minimum is currently set to 0. But if the user sets the property value to zero, the semantics are unclear.
Best to prohibit zero in these cases, since we can later loosen the restriction to allow zero but won't be able to make it more strict.
Cases:
Processor (log, span, periodic metric reader) exporter timeoutProcessor (log, span, periodic metric reader) export internalExporter (otlp, zipkin) timeoutJaeger remote sampler fetch intervalUPDATE (1/13/2025): Updated to reflect the state of things in Spec PR#4331 which now seems poised to merge. Differences from what I originally proposed: