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

Inconsistent Sampling Result Names #938

Merged
merged 3 commits into from
Sep 15, 2020

Conversation

ejsmith
Copy link
Contributor

@ejsmith ejsmith commented Sep 10, 2020

Current Names

  • NOT_RECORD
  • RECORD
  • RECORD_AND_SAMPLED

Seems like we should pick between present tense or past tense and make it consistent. I am proposing that we use past tense as in it's a decision that has already been made.

NOT_RECORD doesn't make sense. It is not correct English.

Proposed Names

  • NOT_RECORDED
  • RECORDED
  • RECORDED_AND_SAMPLED

Related: open-telemetry/opentelemetry-dotnet#1255

- `NOT_RECORD`
- `RECORD`
- `RECORD_AND_SAMPLED`

Seems like we should pick between present tense or past tense and make it consistent. I am proposing that we use past tense as in it's a decision that has already been made. `NOT_RECORDED`, `RECORDED`, `RECORDED_AND_SAMPLED`.

`NOT_RECORD` doesn't make sense. It is not correct English.
@ejsmith ejsmith requested review from a team September 10, 2020 19:16
Copy link
Member

@Oberon00 Oberon00 left a comment

Choose a reason for hiding this comment

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

Thank you! This was already irking me for quite some time. 😄

@Oberon00 Oberon00 added area:api Cross language API specification issue area:sampling Related to trace sampling spec:trace Related to the specification/trace directory labels Sep 11, 2020
@iNikem
Copy link
Contributor

iNikem commented Sep 11, 2020

I think current description of Samplers in Trace SDK is not very clear. I am looking at Java SDK and there sampling response is kinda imperative: it tells SDK to create a Span with specific behaviour (isRecording, isSampled). So it is not past tense like in "some action has been done". It is more "the decision has been made, now act this way".

Therefor I totally agree that names could use some unification, but I think new names should be in imperative mood, not just past tense verbs.

@Oberon00
Copy link
Member

@iNikem I think the spec is clarified in that regard in #932. But I still think that a descriptive terminology is better for an enum.

@iNikem
Copy link
Contributor

iNikem commented Sep 11, 2020

I think the spec is clarified in that regard in #932.

It is, thanks :)

But I still think that a descriptive terminology is better for an enum.

I disagree, but both ways are Ok.

@Oberon00
Copy link
Member

Hmm, what would be the imperative names? DO_NOT_RECORD, RECORD, NEITHER_RECORD_NOR_SAMPLE? I think the last one is awkward but other than that, I would also be OK with imperative names.

@ejsmith
Copy link
Contributor Author

ejsmith commented Sep 11, 2020

I kind of like them being imperative as well. I think the imperative version would be:

  • SKIP
  • RECORD
  • RECORD_AND_SAMPLE

@Oberon00
Copy link
Member

What about IGNORE, RECORD_ONLY, RECORD_AND_SAMPLE?

@ejsmith
Copy link
Contributor Author

ejsmith commented Sep 11, 2020

I'm good with that. They are consistent and I think they make sense.

@Oberon00
Copy link
Member

I now remember there was once confusion about whether IsRecording determines the sampling result or the other way round, see #871 (comment). I think using imperative mood here would actually make this confusion less likely, so I changed my opinion and agree with @iNikem that imperative mood is probably better for this enum.

@andrewhsu
Copy link
Member

@ejsmith if no existing issue filed, can you file one so we can track?

@@ -93,10 +93,10 @@ Returns the sampling Decision for a `Span` to be created.
It produces an output called `SamplingResult` which contains:

* A sampling `Decision`. One of the following enum values:
* `NOT_RECORD` - `IsRecording() == false`, span will not be recorded and all events and attributes
* `IGNORE` - `IsRecording() == false`, span will not be recorded and all events and attributes
Copy link
Member

Choose a reason for hiding this comment

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

Since the description says "will be dropped" here, maybe DROP would be an even better name. I'm fine with IGNORE or SKIP too though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think I like DROP better.

Copy link
Contributor

Choose a reason for hiding this comment

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

+1 for DROP. This is necessary for opentelemetry-cpp because IGNORE is defined as macro as constant. This build failure for details.

Copy link
Member

Choose a reason for hiding this comment

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

@ThomsonTan Then the main problem there seems to be that you have defined a macro constant 😃 And isn't the usual C++ idiom to only have macros/defines in ALL_CAPS? Then you would write SamplingResult::Drop or SamplingResult::drop or similar.

Copy link
Contributor

Choose a reason for hiding this comment

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

@Oberon00 the problem is not defined by opentelemetry-cpp, as IGNORE is sounds like a common word, there is chance of name collision. Change casing in C++ sounds a good suggestion though.

@ejsmith ejsmith changed the title Inconsistent SamplingDecision Names Inconsistent Sampling Result Names Sep 11, 2020
@ejsmith
Copy link
Contributor Author

ejsmith commented Sep 11, 2020

@ejsmith if no existing issue filed, can you file one so we can track?

Filed #940

@Oberon00 Oberon00 linked an issue Sep 11, 2020 that may be closed by this pull request
@bogdandrutu bogdandrutu reopened this Sep 15, 2020
@bogdandrutu bogdandrutu merged commit 4cfcb4d into open-telemetry:master Sep 15, 2020
evantorrie added a commit to open-telemetry/opentelemetry-go that referenced this pull request Sep 21, 2020
MrAlias added a commit to open-telemetry/opentelemetry-go that referenced this pull request Sep 22, 2020
* Rename SamplingDecision enum values

As prescribed in
open-telemetry/opentelemetry-specification#938
and open-telemetry/opentelemetry-specification#956.

* Include in Changelog

Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
shbieng added a commit to shbieng/opentelemetry-go that referenced this pull request Aug 26, 2022
* Rename SamplingDecision enum values

As prescribed in
open-telemetry/opentelemetry-specification#938
and open-telemetry/opentelemetry-specification#956.

* Include in Changelog

Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
carlosalberto pushed a commit to carlosalberto/opentelemetry-specification that referenced this pull request Oct 31, 2024
* Inconsistent SamplingDecision Names

- `NOT_RECORD`
- `RECORD`
- `RECORD_AND_SAMPLED`

Seems like we should pick between present tense or past tense and make it consistent. I am proposing that we use past tense as in it's a decision that has already been made. `NOT_RECORDED`, `RECORDED`, `RECORDED_AND_SAMPLED`.

`NOT_RECORD` doesn't make sense. It is not correct English.

* Use imperative names for sampling result
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:api Cross language API specification issue area:sampling Related to trace sampling spec:trace Related to the specification/trace directory
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Inconsistent Sampling Result Names
10 participants