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

Semconv 1.24.0 #46

Merged
merged 4 commits into from
Mar 26, 2024
Merged

Semconv 1.24.0 #46

merged 4 commits into from
Mar 26, 2024

Conversation

jack-berg
Copy link
Member

Depends on #45.

@jack-berg
Copy link
Member Author

#45 is merged so this is ready for review.

* </ul>
*/
public static final AttributeKey<String> EVENT_DOMAIN = stringKey("event.domain");
Copy link
Member Author

Choose a reason for hiding this comment

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

@lmolkova This is an example of an experimental attribute that was deleted rather retained but marked as deprecated.

Based on what you said, in the future this will not be the case. And we would expect to keep this attribute around semi-permanently marked as deprecated. Is that correct?

Choose a reason for hiding this comment

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

I'm not trying to answer for @lmolkova, and I'm not addressing the general question being asked....but in this specific case I do think it makes sense to remove it, because (experimental) Events are starting to gel and we don't want people using this.

Copy link
Contributor

Choose a reason for hiding this comment

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

sorry, I missed it.
Yes, starting from 1.24.0 we'll have a check that prevents attributes (and metrics) from being deleted - open-telemetry/semantic-conventions#764

It would apply to experimental and stable semconv.

I think we'll need to do the same for events, updated open-telemetry/build-tools#292 so we don't forget

Choose a reason for hiding this comment

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

Thanks, I guess that's fine, as long as they're marked deprecated and can be removed in the subsequent release. I'd hate for us to have constraints that cause long-term maintenance burden due to changes in experimental semconv (and yes, I realize this isn't the place to drag this out, heh 😅 ).

Copy link
Contributor

Choose a reason for hiding this comment

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

Would love to hear your thoughts on removing-experimental-deprecated on open-telemetry/semantic-conventions#740. It'd be great to have a common policy for all language SIGs.

Comment on lines +131 to +133
* Deprecated, use {@code http.request.header.content-length} instead.
*
* @deprecated Deprecated, use `http.request.header.content-length` instead.

Choose a reason for hiding this comment

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

This isn't a showstopper, but it does really a little redundant.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point, but we don't control that text. It comes directly from the semantic conventions YAML: https://github.com/open-telemetry/semantic-conventions/blob/cafda7127683b7f667e27cdbd3220510b6f998c9/model/registry/deprecated/http.yaml#L34

@@ -25,10 +25,6 @@ public final class SystemIncubatingAttributes {
/** The device identifier */
public static final AttributeKey<String> SYSTEM_DEVICE = stringKey("system.device");

/** The disk operation direction */
public static final AttributeKey<String> SYSTEM_DISK_DIRECTION =
Copy link

@breedx-splk breedx-splk Mar 25, 2024

Choose a reason for hiding this comment

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

This might be another set of examples of deleted (not deprecated) semconv?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah I think the process to switch from deleting to deprecating and retaining forever (or at least a while) is a relatively new thing. We just started to see it in 1.24.0, and I expect it will be the norm going forward.

@lmolkova / @trask may be able to confirm.

Copy link

@breedx-splk breedx-splk left a comment

Choose a reason for hiding this comment

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

These are always weird to review, because it's mostly generated code right? In any case, I did review it, seems ok to me.

Copy link
Member

Choose a reason for hiding this comment

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

🎉

@jack-berg
Copy link
Member Author

These are always weird to review, because it's mostly generated code right? In any case, I did review it, seems ok to me.

Its all generated code. To some extent you can rely on the build passing to help give you confidence in the output, since the build will run code generation and detect any difference. The one thing it doesn't check is if there are are files which are part of the commit, but which are not generated anymore. For example, this commit excludes the aspnetcore and signlar root namespaces, but the build would have passed even had I not manually deleted the AspnetcoreIncubatingAttributes and SignalrIncubatingAttributes files.

@jack-berg jack-berg merged commit 24a1f85 into open-telemetry:main Mar 26, 2024
12 checks passed
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.

4 participants