-
Notifications
You must be signed in to change notification settings - Fork 893
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
Centralize attributes definition #722
Conversation
Signed-off-by: Bogdan Drutu <[email protected]>
@open-telemetry/specs-approvers please review |
Co-authored-by: Christian Neumüller <[email protected]>
@Oberon00 thanks for catching my copy paste :) |
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.
In general looks good to me, just some nitpicks.
`null` values within arrays MUST be preserved as-is (i.e., passed on to span | ||
processors / exporters as `null`). If exporters do not support exporting `null` | ||
values, they MAY replace those values by 0, `false`, or empty strings. | ||
This is required for map/dictionary structures represented as two arrays with |
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.
Is the required here a MUST overriding the previous MAY? I'm not sure how to interpret this sentence
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.
This is a note that explains the rationale for both of the above together. It is meant to ban SDKs and exporters from just dropping the null values from the array (changing the index of following elements).
null
values within arrays MUST be preserved as-is
Is what basically applies.
exporters [...] MAY replace those values
This is a relaxation for exporters. Notice how they MAY replace those values, but we do not allow them to drop them. So if they choose not to exercise the MAY, the "null
values within arrays MUST be preserved as-is" applies.
That is how I read it, and I'm pretty sure that's how it was meant originally (CC @arminru). But it could be worded more clearly.
Co-authored-by: Christian Neumüller <[email protected]>
Co-authored-by: Christian Neumüller <[email protected]>
Co-authored-by: Christian Neumüller <[email protected]>
Co-authored-by: Christian Neumüller <[email protected]>
Co-authored-by: Christian Neumüller <[email protected]>
Co-authored-by: Christian Neumüller <[email protected]>
Actually we should add a release notes entry for this since this adds arrays as allowed resource attribute value type. @bogdandrutu |
* Centralize attributes definition Signed-off-by: Bogdan Drutu <[email protected]> * Update specification/common/common.md Co-authored-by: Christian Neumüller <[email protected]> * Update specification/common/common.md Co-authored-by: Christian Neumüller <[email protected]> * Update specification/common/common.md Co-authored-by: Christian Neumüller <[email protected]> * Update specification/common/common.md Co-authored-by: Christian Neumüller <[email protected]> * Update specification/common/common.md Co-authored-by: Christian Neumüller <[email protected]> * Update specification/common/common.md Co-authored-by: Christian Neumüller <[email protected]> * Update specification/overview.md Co-authored-by: Christian Neumüller <[email protected]> Co-authored-by: Christian Neumüller <[email protected]>
Fixes #425
Fixes #446
Changes
Found Attributes defined in at least 3 different places, with different requirements. This PR tries to centralize the definition for the Attributes in a common place and share across (for the moment resources and traces).