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

chore: adopt opentelemetry-propagator-jaeger #1931

Merged

Conversation

jtmalinowski
Copy link
Contributor

@jtmalinowski jtmalinowski commented Feb 15, 2021

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

  • moves opentelemetry-propagator-jaeger from contrib into core, allowing other core packages to rely on it

@codecov
Copy link

codecov bot commented Feb 15, 2021

Codecov Report

Merging #1931 (ab14ebc) into main (a707588) will decrease coverage by 0.23%.
The diff coverage is 100.00%.

❗ Current head ab14ebc differs from pull request most recent head 550ae3f. Consider uploading reports for the commit 550ae3f to get more accurate results

@@            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     
Impacted Files Coverage Δ
...propagator-jaeger/src/JaegerHttpTracePropagator.ts 100.00% <100.00%> (ø)
...mentation-xml-http-request/src/enums/EventNames.ts
...ntelemetry-web/src/enums/PerformanceTimingNames.ts
...ackages/opentelemetry-web/src/WebTracerProvider.ts
...emetry-instrumentation-xml-http-request/src/xhr.ts
packages/opentelemetry-web/src/utils.ts
...kages/opentelemetry-web/src/StackContextManager.ts
packages/opentelemetry-web/src/types.ts

@vmarchaud
Copy link
Member

Default Node Tracer Provider needs to depend on Jaeger propagator.

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 ?

@jtmalinowski
Copy link
Contributor Author

jtmalinowski commented Feb 15, 2021

@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. peerdependencies generates warnings, so in the end we decided to just pull it in. Let me know if it's an issue.
Edit: in general for this ENV based configuration to work, we need either:

  • propagator packages to depend on a "propagators store", e.g. opentelemetry-core - I think someone was against that, but I can't remember why
  • or: the package with the Tracer to depend on on propagator packages

@vmarchaud
Copy link
Member

vmarchaud commented Feb 15, 2021

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

@jtmalinowski
Copy link
Contributor Author

@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?

@dyladan
Copy link
Member

dyladan commented Feb 16, 2021

Maybe it's best to quickly discuss this during SIG?

Can you please add it to the agenda?

@vmarchaud
Copy link
Member

1st party propagators in core and loading out of the box seems like a good user experience to me

Agree, lets discuss this at the SIG indeed

Copy link
Contributor

@MSNev MSNev left a 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".

https://medium.com/@ayushya/move-directory-from-one-repository-to-another-preserving-git-history-d210fa049d4b

@dyladan
Copy link
Member

dyladan commented Feb 19, 2021

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".

medium.com/@ayushya/move-directory-from-one-repository-to-another-preserving-git-history-d210fa049d4b

I have done this multiple times. The best way I have found to do it is to use git-filter-repo, then you rebase that onto the new repository.

  1. get a fresh clone of the source repo
  2. use git-filter-repo to filter the source repo down to only the files you need
    • git-filter-repo --path propagators/opentelemetry-propagator-jaeger --path-rename propagators/opentelemetry-propagator-jaeger:packages/opentelemetry-propagator-jaeger
  3. add the target repo as a remote on your source clone
  4. rebase the source on the target main
    • git fetch core
    • git rebase core/main
      • during this step you may need to use the -i flag to edit any commits with invalid CLA
  5. push the source branch to a new branch on the target
    • git push core HEAD:jaeger
  6. Create a pull request from that branch to main
  7. Create new commits on the branch for any compatibility changes that need to be made like the tsconfig references and such.

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 filter-branch method from that blog post and it is indeed not fun.

@vmarchaud
Copy link
Member

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.

@dyladan
Copy link
Member

dyladan commented Feb 24, 2021

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.

@vmarchaud
Copy link
Member

@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 ?

@vmarchaud
Copy link
Member

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 cp from the contrib (see open-telemetry/opentelemetry-js-contrib#351)

@@ -0,0 +1,63 @@
# OpenTelemetry Propagator Jaeger

[![Gitter chat][gitter-image]][gitter-url]
Copy link
Member

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]
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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"
Copy link
Member

Choose a reason for hiding this comment

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

8.5.0

Copy link
Contributor Author

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!

Copy link
Member

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).

@vmarchaud vmarchaud self-requested a review March 20, 2021 18:07
@dyladan
Copy link
Member

dyladan commented Mar 24, 2021

@jtmalinowski are you still working on this? There are several open comments over a week old

@jtmalinowski
Copy link
Contributor Author

@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.

@dyladan
Copy link
Member

dyladan commented Mar 24, 2021

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?

@jtmalinowski
Copy link
Contributor Author

@dyladan Sure, that makes sense. I'll address the comments within 2-3 days.

@jtmalinowski
Copy link
Contributor Author

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:

  • one final interactive rebase right before merging
  • interactive rebase to remove "merge main" commits
  • squash all my changes into 1 commit
  • merge PR using rebase-merge

If you don't mind non-linear history then just rebase-merge should be fine.

@dyladan
Copy link
Member

dyladan commented Mar 29, 2021

I don't mind nonlinear history. I'm more worried about accurate blames than the timeline.

Copy link
Member

@obecny obecny left a comment

Choose a reason for hiding this comment

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

lgtm

@dyladan dyladan closed this Mar 29, 2021
@dyladan dyladan reopened this Mar 29, 2021
@dyladan dyladan merged commit 4fc4a85 into open-telemetry:main Mar 29, 2021
pichlermarc pushed a commit to dynatrace-oss-contrib/opentelemetry-js that referenced this pull request Dec 15, 2023
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet