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

Change the default javaagent artifact to have exporters #4106

Merged
merged 26 commits into from
Oct 2, 2021
Merged

Change the default javaagent artifact to have exporters #4106

merged 26 commits into from
Oct 2, 2021

Conversation

trask
Copy link
Member

@trask trask commented Sep 13, 2021

And introduce a new artifact with classifier "slim" which does not have any exporters (same as what used to be the default artifact). EDIT: which has only otlp/grpc (and using okhttp instead of netty for size)

Resolves #3959

Will send separate PR to be merged after the release updating:

asset_path: javaagent/build/libs/opentelemetry-javaagent-${{ github.event.inputs.version }}-all.jar
asset_name: opentelemetry-javaagent-all.jar
asset_path: javaagent/build/libs/opentelemetry-javaagent-${{ github.event.inputs.version }}.jar
asset_name: opentelemetry-javaagent.jar
Copy link
Contributor

Choose a reason for hiding this comment

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

I agree with the rename but it's sort of a breaking change for e.g., Dockerfiles that may be curling the "latest release" URL. Should we upload both at least for one release?

We may also consider whether it is bad practice in general to point at an unversioned URL - if so we can probably update our README to not point at the latest version URL to discourage usage.

Copy link
Member Author

Choose a reason for hiding this comment

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

Should we upload both at least for one release?

makes sense to me, I added attaching backwards compatible "all" artifact step to both release and patch release builds

update our README to not point at the latest version URL to discourage usage

I like explicit versions in docs (and keeping it updated), IIRC we were stuck on how to automate this? maybe we can tack this problem on to #3516 @iNikem?

docs/manual-instrumentation.md Outdated Show resolved Hide resolved
Comment on lines 52 to 53
// TODO (trask) this needs to be updated now that no more "all" artifact
return "all".equals(classifier) && "jar".equals(extension);
Copy link
Member Author

Choose a reason for hiding this comment

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

@breedx-splk any idea with this change if the classifier check should be changed to "" or null?

Copy link
Contributor

Choose a reason for hiding this comment

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

Is the idea here that we'll be publishing the full agent with exporters now without the -all classifier? If so, then I think we should just remove the classifier check entirely.

It looks like you're also publishing -all for backwards compat? Assuming that's temporary, yeah, I think we'll want to remove this classifier check...but it might be nice to see what the xml looks like after the first publish to confirm.

Copy link
Member Author

Choose a reason for hiding this comment

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

the -all artifact will be attached to the github release for now for backwards compatibility, but won't be published.

there will be a new artifact -slim published after this tho

it might be nice to see what the xml looks like after the first publish to confirm

this works for me 👍

@iNikem
Copy link
Contributor

iNikem commented Sep 13, 2021

I vaguely remember that we wanted to make this change after extracting contrib portion. To minimize the number of times we change the meaning of our artifacts.

@trask
Copy link
Member Author

trask commented Sep 13, 2021

I vaguely remember that we wanted to make this change after extracting contrib portion. To minimize the number of times we change the meaning of our artifacts.

I added to tomorrow's meeting agenda

@trask
Copy link
Member Author

trask commented Sep 14, 2021

I vaguely remember that we wanted to make this change after extracting contrib portion. To minimize the number of times we change the meaning of our artifacts.

I added to tomorrow's meeting agenda

moving back to draft for now and deferring until after the 1.6.0 release

@trask trask marked this pull request as draft September 14, 2021 05:43
@trask
Copy link
Member Author

trask commented Sep 23, 2021

moving back to draft for now and deferring until after the 1.6.0 release

we discussed in SIG meetings this week, and I think there's general agreement to go forward with this PR now (see discussion in #3959)

I'll raise once more in next Tue SIG meeting and will merge after that if there's still agreement.

@trask
Copy link
Member Author

trask commented Sep 23, 2021

and will add otlp/http exporter to "-slim" as a follow-up PR (for now in this PR "-slim" has no exporters, same as the previous default artifact)

@@ -73,6 +78,10 @@ dependencies {

exporterLibs(project(":javaagent-exporters"))

exporterSlimLibs("io.opentelemetry:opentelemetry-exporter-otlp")
exporterSlimLibs("io.opentelemetry:opentelemetry-exporter-otlp-metrics")
exporterSlimLibs("io.grpc:grpc-okhttp:1.41.0")
Copy link
Contributor

Choose a reason for hiding this comment

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

Just realized that because this is using okhttp, adding the HTTP exporters as well should be almost no additional bytecode, so maybe worth it?

Copy link
Contributor

Choose a reason for hiding this comment

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

Well assuming it doesn't cause dependency hell, wow that's old

https://github.com/grpc/grpc-java/blob/master/build.gradle#L158

Copy link
Contributor

Choose a reason for hiding this comment

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

Err - nevermind, yeah it wouldn't cause dependency hell since it's a different artifact

https://github.com/open-telemetry/opentelemetry-java/blob/main/dependencyManagement/build.gradle.kts#L78

So scratch the almost-no-additional-bytecode idea.

Copy link
Contributor

Choose a reason for hiding this comment

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

By the way, just some random trivia grpc/grpc-java#6119 (comment)

Copy link
Member Author

Choose a reason for hiding this comment

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

"OkHttp" name for the transport is a bit of a misnomer

this thread helped my mental picture 👍

Copy link
Contributor

Choose a reason for hiding this comment

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

It appears that we can exclude okhttp 2 from the transitive dependencies

open-telemetry/opentelemetry-java#3678

though I added a comment on the grpc-java issue to see if there is anything obviously bad with that.

Currently I guess we effectively have two copies of okhttp2, the forked-into-grpc one and the transitive dependency which we don't seem to need.

Copy link
Member Author

Choose a reason for hiding this comment

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

I added #4240 to discuss/track

@trask trask marked this pull request as ready for review September 29, 2021 05:38
Comment on lines -21 to -25
> :warning: prior to version 1.0.0, `opentelemetry-javaagent-all.jar`
only supports manual instrumentation using the `opentelemetry-api` version with the same version
number as the Java agent you are using. Starting with 1.0.0, the Java agent will start supporting
multiple (1.0.0+) versions of `opentelemetry-api`.

Copy link
Contributor

Choose a reason for hiding this comment

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

Are we sure about that? Have we tested that?

Copy link
Member Author

Choose a reason for hiding this comment

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

we have a smoke test that verifies interop with opentelemetry-api 1.0.0, and #3044 to track doing better than that with muzzle

(also, this is old doc, I'm removing it, see #4106 (comment))

@@ -164,17 +184,15 @@ tasks {
}
}

// Includes everything needed for OOTB experience
val fullJavaagentJar by registering(ShadowJar::class) {
// Includes instrumentations, but not exporters
Copy link
Contributor

Choose a reason for hiding this comment

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

Slim does include OTLP exporter, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

fixed 👍

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.

Make opentelemetry-javaagent "all" artifact the default artifact
5 participants