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

Stabilize AddLink operation in Trace API #3865

Closed
Tracked by #659
pellared opened this issue Feb 7, 2024 · 10 comments · Fixed by #3887
Closed
Tracked by #659

Stabilize AddLink operation in Trace API #3865

pellared opened this issue Feb 7, 2024 · 10 comments · Fixed by #3887
Assignees
Labels
[label deprecated] triaged-accepted [label deprecated] Issue triaged and accepted by OTel community, can proceed with creating a PR spec:trace Related to the specification/trace directory

Comments

@pellared
Copy link
Member

pellared commented Feb 7, 2024

What are you trying to achieve?

Mark https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#add-link as stable.

@pellared pellared added the spec:trace Related to the specification/trace directory label Feb 7, 2024
@pyohannes
Copy link
Contributor

cc @carlosalberto, who is working on stabilizing this.

@jack-berg
Copy link
Member

The add link operation was discussed extensively before merging, but was straight forward to implement once we agreed that was the direction we wanted to go. I don't see any reason why we should delay stabilization.

@cijothomas
Copy link
Member

https://github.com/open-telemetry/opentelemetry-specification/blob/main/spec-compliance-matrix.md#traces This shows only OTel C++ has implemented this. Most likely this matrix is out-of-date.

@carlosalberto Could you help to make this matrix updated, so it is easy to tell who all have implemented this?

@jack-berg
Copy link
Member

Most likely this matrix is out-of-date.

In java, I've only been updating the compliance matrix once we have stable support for something. Not sure this is correct, since it eliminates the spec compliance matrix as a tool for evaluating the stability readiness of experimental features. Maybe I could populate the cell with a symbol which conveys the feature is available but experimental?

@cijothomas
Copy link
Member

cijothomas commented Feb 9, 2024

Most likely this matrix is out-of-date.

In java, I've only been updating the compliance matrix once we have stable support for something. Not sure this is correct, since it eliminates the spec compliance matrix as a tool for evaluating the stability readiness of experimental features. Maybe I could populate the cell with a symbol which conveys the feature is available but experimental?

There was no specific guidelines about when should the matrix be filled in - whether it is done after feature is done in stable or just preview/experimental. Your suggestion of using some symbol to indicate experimental/preview is good! (Though we may need to establish and apply that convention for everything else in the matrix already)

edit: The existing matrix shows Exemplars in Java, though they are still experimental....

@jack-berg
Copy link
Member

The exemplars example is strange. In java, we turn on exemplars by default even tho they are experimental. We justified this for a variety of reasons, including that exemplars are stable in the data model. However, the APIs for configuring exemplars are still experimental.

So exemplars are a bit of an oddity for java - somewhere in between stable / experimental - but generally I've resisted filling out the compliance matrix until stable.

@carlosalberto
Copy link
Contributor

Btw, one important point in order to stabilize this is deciding on a way to tell whether a Link was added before OR after Span creation. We had talked in the past about timestamp either as an attribute or an OTLP field, which was also of interest to the Sampling SIG, but it turns out (based on a conversation I had with them last Thursday), this is not the case anymore.

So overall, the question is how important it is to have such timestamp, if any?

cc @Oberon00

@carlosalberto
Copy link
Contributor

Related to #3698

@jack-berg
Copy link
Member

We're waiting to decide if #3698 is a prerequisite for stabilization. This was discussed in the 2/13/24 spec SIG, and nobody expressed an opinion that #3698 was blocking. Will give a few more days for anyone to speak up that this is blocking.

@jack-berg jack-berg added the [label deprecated] triaged-accepted [label deprecated] Issue triaged and accepted by OTel community, can proceed with creating a PR label Feb 14, 2024
carlosalberto added a commit that referenced this issue Mar 8, 2024
Fixes #3865 

Enough SIGs have implemented prototypes without any concern. Also, no
actual need to detect whether links were added before or after Span
creation has received further attention, which previously was a blocker.
carlosalberto added a commit to carlosalberto/opentelemetry-specification that referenced this issue Oct 31, 2024
Fixes open-telemetry#3865 

Enough SIGs have implemented prototypes without any concern. Also, no
actual need to detect whether links were added before or after Span
creation has received further attention, which previously was a blocker.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[label deprecated] triaged-accepted [label deprecated] Issue triaged and accepted by OTel community, can proceed with creating a PR spec:trace Related to the specification/trace directory
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants