Skip to content
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

Remove helper masks, not part of the protocol #423

Closed
wants to merge 1 commit into from

Conversation

bogdandrutu
Copy link
Member

Fixes #363

The reason is to keep the proto interface as minimal as possible, and the helper masks are just helpers, and not part of the protocol. They can be defined by the language SIGs in their usages, but don't need to be part of the proto stability.

Signed-off-by: Bogdan Drutu bogdandrutu@gmail.com

Fixes open-telemetry#363

The reason is to keep the proto interface as minimal as possible, and the helper masks are just helpers, and not part of the protocol. They can be defined by the language SIGs in their usages, but don't need to be part of the proto stability.

Signed-off-by: Bogdan Drutu <bogdandrutu@gmail.com>
Copy link
Member

@tigrannajaryan tigrannajaryan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The definitions of the bits in the flags field is an essential part of OTLP protocol. In my opinion, having these definitions in the form helper enums is valuable and helps prevent implementation mistakes. Because of this I would prefer to keep the helper enums.

@MikeGoldsmith
Copy link
Member

Yeah, I agree - these helper numbers help ensure there isn't language implementation drift. I would vote to keep them.

@bogdandrutu
Copy link
Member Author

May help, but not part of the protocol and guarantees. I am definitely not going to accept this as part of our guarantees of stability.

@jmacd
Copy link
Contributor

jmacd commented Aug 17, 2022

How can FLAG_NO_RECORDED_VALUE not be considered part of a stability guarantee? Are you saying that you'd like to reserve the right to change the name of the symbol so that NO_RECORDED_VALUE could be renamed? The meaning of this field has to be considered stable IMO.

@bogdandrutu
Copy link
Member Author

The meaning of this field has to be considered stable IMO.

100% agree

Are you saying that you'd like to reserve the right to change the name of the symbol so that NO_RECORDED_VALUE could be renamed?

YES

@tigrannajaryan
Copy link
Member

I wonder what other @open-telemetry/specs-approvers think about usefulness of these enums.

My preference would be to keep them, but it is not a strong opinion.

Also, we should get rid of the zero values: LOG_RECORD_FLAG_UNSPECIFIED and FLAG_NONE since they encourage poor practice. The correct usage is to always do bitwise AND with the right bit, never compare to the 0 value.

@jsuereth
Copy link
Contributor

I'm w/ @tigrannajaryan in that I think having them here is generally helpful and helps us avoid (obvious) breaking changes in their definition as well as gives folks "one pane of glass" to look at.

@bogdandrutu
Copy link
Member Author

I'm w/ @tigrannajaryan in that I think having them here is generally helpful and helps us avoid (obvious) breaking changes in their definition as well as gives folks "one pane of glass" to look at.

This is a protocol not a "helper" library. I don't think these constants belong to the protocol, similar to a standard like w3c trace context, does not require/define/encourage a constant for 0x1 for the sampling bit, it is who is generating the code responsibility if they want to provide helpers.

// This DataPoint is valid but has no recorded value. This value
// SHOULD be used to reflect explicitly missing data in a series, as
// for an equivalent to the Prometheus "staleness marker".
FLAG_NO_RECORDED_VALUE = 1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where did this flag go?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the idea is to remove it in favor of comments describing values that can be used in data point flags. I believe that is a mistake. Having an enumeration allows for clearly named consistent values and separate documentation of each potential flag.

@jmacd
Copy link
Contributor

jmacd commented May 2, 2023

I disagree with the effort to protect users from being foolish. I support the idea of removing zero-valued enums, but not removing non-zero values. The FLAG_NO_RECORDED_VALUE has disappeared, which I do not support. Users who use bitmasks should know what they are doing and/or read documents.

@tigrannajaryan
Copy link
Member

Discussed in TC meeting and decided that #461 should be sufficient and we can close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Revisit enum value names
6 participants