-
Notifications
You must be signed in to change notification settings - Fork 446
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
Use weaver for semantic convention codegen #2098
Conversation
…e.rs and trace.rs
@@ -20,54 +20,24 @@ git fetch origin "v$SPEC_VERSION" | |||
git reset --hard FETCH_HEAD | |||
cd "$CRATE_DIR" | |||
|
|||
docker run --rm \ |
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.
We only need to call Weaver once, as the weaver.yaml
file specifies what needs to be generated.
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.
Per my understanding this PR only changes the generation tool we use. The end results are still a list of static string right?
opentelemetry-semantic-conventions/scripts/templates/registry/rust/attribute.rs.j2
Show resolved
Hide resolved
Yes, the initial intent was to minimize differences with the existing code generation first and then propose a more advanced integration that removes static strings entirely. However, if the community prefers to move directly to a step where static strings are replaced, such as for attribute declarations like:
I am happy to update this PR accordingly. This would be straightforward since I already have a proof of concept (POC) for the step 2 described in #2100. Even if we don’t move directly to step 2, which is a fully type-safe API for Rust semconv, we could create an intermediate step (let’s call it step 1.5) where static strings are no longer visible to users or the compiler. I’d appreciate more feedback on this approach. |
@@ -1,60 +1,79 @@ | |||
// DO NOT EDIT, this is an auto-generated file | |||
// | |||
// If you want to update the file: | |||
// - Edit the template at scripts/templates/semantic_attributes.rs.j2 | |||
// - Edit the template at scripts/templates/registry/rust/attributes.rs.j2 |
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.
The attributes.rs file currently defines semconv constants, which are then re-exported in various other modules (ie trace.rs, metrics.rs, resource.rs). If there aren't any (or too many) shared definitions used across multiple modules, would it make sense to move these constants to their respective modules where they actually belong? The attributes.rs can grow over time as we add more definitions, and add the semconv for logs later, could be difficult to manage even though auto-generated.
I know this has been the existing behavior, but then right time to decide any such change.
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.
Just to add - this is not a blocker for the PR, something to discuss and plan for subsequent if all agree.
@lquerel This looks awesome - in this case it will ensure that HTTP_REQUEST_METHOD will always have valid HTTP verbs. Just thinking in terms of the performance - we will possibly encapsulate these verbs in enum, and then encapsulate the |
opentelemetry-semantic-conventions/scripts/templates/registry/rust/metric.rs.j2
Outdated
Show resolved
Hide resolved
opentelemetry-semantic-conventions/scripts/templates/registry/rust/attribute.rs.j2
Outdated
Show resolved
Hide resolved
opentelemetry-semantic-conventions/scripts/templates/registry/rust/metric.rs.j2
Outdated
Show resolved
Hide resolved
opentelemetry-semantic-conventions/scripts/templates/registry/rust/metric.rs.j2
Outdated
Show resolved
Hide resolved
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2098 +/- ##
=====================================
Coverage 79.0% 79.0%
=====================================
Files 121 121
Lines 20933 20933
=====================================
Hits 16549 16549
Misses 4384 4384 ☔ View full report in Codecov by Sentry. |
@lalitb I’ve fixed most of the issues, but there are still a few problems related to unescaped markdown links in the semconv registry. |
Thanks @lquerel. It seems if the CI is breaking, we need to wait for the next release. When is it planned? |
@lalitb We are targeting a new release at the beginning of next week. |
@lalitb @cijothomas Weaver release v0.10.0 fixed the issue with non-escaped invalid links present in the semconv registry that were causing problems with cargo doc. This PR is now ready for final review. |
"${SED[@]}" "s/\(opentelemetry.io\/schemas\/\)[^\"]*\"/\1$SPEC_VERSION\"/" scripts/templates/registry/rust/weaver.yaml | ||
|
||
docker run --rm \ | ||
--mount type=bind,source=$CRATE_DIR/semantic-conventions/model,target=/home/weaver/source,readonly \ |
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.
For another review: This binding method seems to be incompatible with SELinux systems.
Is there a particular advantage ?
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.
Yes, there are advantages. For context, I’ve copied the relevant change log entry below.
(#322, #312,
#319, #318,
#312, #304
by @jsuereth ) Many improvements have been made to the creation of the Weaver Docker image,
which is now scoring an A on the Scout Docker image score.
- Add Weaver docker image to dependabot tracking,
- Add build attestations,
- Stop using root user the docker image,
- Use official docker action to build docker image,
Update docker to use release build.
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.
LGTM. Thanks for getting start with this
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.
LGTM to start with. Thanks
Co-authored-by: Zhongyang Wu <[email protected]> Co-authored-by: Lalit Kumar Bhasin <[email protected]>
Changes
This PR marks the first step in the migration to Weaver for semconv code generation. The following changes have been made:
semconv_experimental
feature.Note: This PR represents the first step of the plan described here.
Merge requirement checklist
CHANGELOG.md
files updated for non-trivial, user-facing changes