-
Notifications
You must be signed in to change notification settings - Fork 804
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
chore: adopt opentelemetry-propagator-jaeger #1931
chore: adopt opentelemetry-propagator-jaeger #1931
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1931 +/- ##
==========================================
- Coverage 93.00% 92.77% -0.24%
==========================================
Files 152 146 -6
Lines 5944 5547 -397
Branches 1237 1161 -76
==========================================
- Hits 5528 5146 -382
+ Misses 416 401 -15 |
3460398
to
ca882b1
Compare
Sorry but i can't find in the spec where they require to install jeager propagator by default on the node tracer, unless i misunderstood ? |
@vmarchaud so the basic requirements are here https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/sdk-environment-variables.md#general-sdk-configuration, see "Known values for OTEL_PROPAGATORS are:". We have discussed a couple of approaches back in early January and we never managed to come up with a good optional dependency approach. E.g.
|
Well i'm not sure if that means the sdk need to be able to instantiate all of them ? I mean there are values for vendor specific propagator |
@vmarchaud Thanks for the time to review! Last time it was discussed there were no 3rd party propagators, now there are. 1st party propagators in core and loading out of the box seems like a good user experience to me. I'm not sure what to do about 3rd party propagators. Maybe it's best to quickly discuss this during SIG? |
Can you please add it to the agenda? |
Agree, lets discuss this at the SIG indeed |
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.
Is it possible to try doing this while preserving the history? I've never done this and it doesn't look like fun, but it would be "nice".
I have done this multiple times. The best way I have found to do it is to use
The biggest issue is ensuring all commit authors have signed the CLA. It shouldn't be a problem for us though because it is our repo. I've also done the |
ca882b1
to
4dd4427
Compare
Seeing the result of importing the history i would prefer to not import it at all, we will have release commit from contrib inside the core which i think will give us trouble later to understand what happened. Since all commits reference their PR for the context, i think it should be enough to squash everything. |
Squash looses the blames and the dates things happened which can be useful when debugging issues later. I personally use blame all the time to figure out who to ask about certain things. The release commits are different because these will be the release dates of the jaeger propagator (contrib) not the core repo. I think we can keep everything. |
@jtmalinowski I think we can move this forward, could you upgrade to use the version 0.18.0 of the API as the rest of the repo ? |
We need to merge this before merging open-telemetry/opentelemetry-js-contrib#351 so the propagator exists in one of our repo. cc @open-telemetry/javascript-approvers can someone review this ? This is a simple |
@@ -0,0 +1,63 @@ | |||
# OpenTelemetry Propagator Jaeger | |||
|
|||
[![Gitter chat][gitter-image]][gitter-url] |
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.
pls remove it
|
||
* For more information on OpenTelemetry, visit: <https://opentelemetry.io/> | ||
* For more about OpenTelemetry JavaScript: <https://github.com/open-telemetry/opentelemetry-js> | ||
* For help or feedback on this project, join us on [gitter][gitter-url] |
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.
pls remove it
|
||
[gitter-image]: https://badges.gitter.im/open-telemetry/opentelemetry-js.svg | ||
[gitter-url]: https://gitter.im/open-telemetry/opentelemetry-node?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge | ||
[license-url]: https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/LICENSE |
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.
wrong link, please update he rest links too so they point to core repo
@@ -0,0 +1,24 @@ | |||
/*! | |||
* Copyright 2020, OpenTelemetry Authors |
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.
please fix the headline
"author": "OpenTelemetry Authors", | ||
"license": "Apache-2.0", | ||
"engines": { | ||
"node": ">=8.0.0" |
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.
8.5.0
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.
There seems to be a number of places where 8.0.0
is still specified (e.g. https://github.com/open-telemetry/opentelemetry-js/blob/main/packages/opentelemetry-exporter-jaeger/package.json#L29), is there some kind of a rule for this? Anyway, fixed!
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.
When we started the project we simply started with node 8.0.0
support because that was the same as opencensus, however at some point we started to use perf_hooks
which is only available starting 8.5.0
. We then choose to up the minimum version for all new packages to 0.8.5
to keep consistency across the core packages (then same logic for contribs).
@jtmalinowski are you still working on this? There are several open comments over a week old |
@dyladan To be honest, I don't think I'll have enough time to ensure smooth progress of this feature (specification env vars) within the next couple of weeks, so it's probably best if you reassign it to someone else. Unless you're fine if it's resumed in late April. |
it's fine if you don't have time for the ENV var feature, but we should at least try to bring the jaeger package across with no other changes yes? |
@dyladan Sure, that makes sense. I'll address the comments within 2-3 days. |
e680d9c
to
f92a2db
Compare
Apologies, I had to force-push, because someone merged main in the meantime and there would otherwise be quite a lot of git history straightening for me locally. @dyladan in terms of final commit structure, because we can't squash-merge for linear history, I suggest:
If you don't mind non-linear history then just rebase-merge should be fine. |
I don't mind nonlinear history. I'm more worried about accurate blames than the timeline. |
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
Move opentelemetry-propagator-jaeger from contrib to core (open-telemetry#1931). This is to enable turning on the jaeger propagator using ENV variables. Default Node Tracer Provider needs to depend on Jaeger propagator.
Move opentelemetry-propagator-jaeger from contrib to core.
This is to enable turning on the jaeger propagator using ENV variables.
Default Node Tracer Provider needs to depend on Jaeger propagator.
Which problem is this PR solving?
Short description of the changes