-
Notifications
You must be signed in to change notification settings - Fork 297
all: add notes about the attribute values restrictions #683
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The OTEP says
but IMO we effectively still create a new convention of "plain old standard attributes", spelling it in plain text like comments in this PR. I think it would be better to have an explicit name for it. |
The intent of this PR is to describe the current state of art. You can consider this PR as a "bugfix". Thanks to it would be easier for us to communicate future changes in the OTLP protocol (new supported attribute types). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hit approve too quickly 😅
(The same typo is repeated in the other signals)
No worries. Fixes applied 😉 |
…hange (#4614) Towards #4602 Per OTEP: https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md#why-doesnt-this-require-a-major-version-bump This basically reverts: - #3858 Before we did not have a consensus to extend the attribute value types. However, this has changed with: - #4485 Related proto PR: - open-telemetry/opentelemetry-proto#683 **As a follow-up I plan to create issues in all language repositories so that they can prepare their APIs and SDKs to extend the attribute value types.** --------- Co-authored-by: Trask Stalnaker <[email protected]>
### Changed - profiles: drop gzip requirement. [#661](#661) - profiles: avoid `optional` keyword usage. [#659](#659) - profiles: make `profile_id` optional. [#665](#665) - profiles: use single `Profile.sample_type` and clarify use of timestamps. [#649](#649) - all: add notes about the attribute values restrictions. [#683](https://github.com/open-telemetry/opentelemetry-proto/pull/683)<br>⚠️ **IMPORTANT**: These restrictions can be dropped in a future minor release. - profiles: clarify usage of the zero value as the first element of tables in `ProfilesDictionary`. [#688](#688), [#698](#698) - profiles: unsigned `time_nanos` and `duration_nanos` in `Profile`. [#692](#692) - profiles: improve attribute encoding in `ProfilesDictionary`. [#672](#672) - profiles: simplify profile stack trace representation. [#708](#708) ### Fixed - examples: fix OTLP JSON Event example body. [#666](#666) - docs: minor specification fixes around `UNAVAILABLE` and `RetryInfo`. [#669](#669) ### Removed - profiles: remove `default_sample_type`. [#679](#679) - profiles: remove `has_*` debug info fields, they are moving to attributes. [#595](#595) - profiles: remove `Location.is_folded`. [#690](#690)
Per open-telemetry/opentelemetry-specification#4595 (comment)
Towards https://github.com/open-telemetry/opentelemetry-specification/blob/8aa1d27d9cf8c224299dcf0b58bfd5fcaacf88eb/oteps/4485-extending-attributes-to-support-complex-values.md?plain=1#L223-L227
The intent of this PR is to describe the current state of art.
You can consider this PR as a "bugfix". Thanks to it would be easier for us to communicate future changes in the OTLP protocol (new supported attribute types).
Related OTEP: https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md
Some of the language is based on JSON RFC https://datatracker.ietf.org/doc/html/rfc8259#section-4:
Notice that this kind of description should be present in the comments even without the intent to go forward with https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md
Related spec PR: