Replace inferred-spans extension with upstream contrib extension #370
Conversation
# Conflicts: # inferred-spans/build.gradle.kts
JonasKunz
force-pushed
the
inferred-spans-upstream
branch
from
a874dbb to
8aa033c
Compare
# Conflicts: # inferred-spans/README.md # inferred-spans/src/main/java/co/elastic/otel/profiler/InferredSpansAutoConfig.java # inferred-spans/src/test/java/co/elastic/otel/InferredSpansAutoConfigTest.java # licenses/more-licences.md
|
Support for |
|
Waiting on open-telemetry/opentelemetry-java-contrib#1533 to implement full backwards compatibility |
# Conflicts: # inferred-spans/README.md # licenses/more-licences.md
# Conflicts: # gradle/libs.versions.toml
|
open-telemetry/opentelemetry-java-contrib#1533 is now part of the included contrib version, so this PR is ready for review |
inferred-spans/src/test/java/co/elastic/otel/InferredSpansBackwardsCompatibilityConfigTest.java
Outdated
Show resolved
Hide resolved
inferred-spans/src/test/java/co/elastic/otel/InferredSpansBackwardsCompatibilityConfigTest.java
Show resolved
Hide resolved
|
are we still going to be generating an extension jar that will be included in the docker image? |
Not sure what you mean exactly with an "extension jar that will be included in the docker image" ? I don't think it is worth anymore to publish this inferred-spans variant on maven-central anymore, because it is now just acompatibility layer for legacy options. Therefore I've removed the maven publish in 6b62114. However, we'll still be publishing it as part of the agentextension jar which allows you to load all our distro features into a vanilla agent. But I don't think we put this jar in our docker image, do we? |
Yes, we do. The docker image is set up for the otel operator so that it can be used both as an image for running the agent and separately as an image to include our extensions. The latter requires the agentextension jar to be in a specific location. So your answer is ultimately yes :-) |
Closes #174.
Replaces the inferred-spans extension with the contributed upstream one, but maintains a backwards compatibility layer for the
ELASTIC_options because they are used a lot already in demos.This PR is also kind of blocked by elastic/apm-data#321. That change did not make it into
8.15. We'll need that change to ship, otherwise the parent-child overriding won't wokr correctly, because the attributeelastic.is_childwas renamed tois_child.