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

feat(experimental-packages): Update packages to latest SDK Version. #2871

Merged

Conversation

pichlermarc
Copy link
Member

@pichlermarc pichlermarc commented Mar 28, 2022

Which problem is this PR solving?

This PR

  • removes the -wip suffix from api-metrics and metrics-sdk-base, this causes lerna to link the local version of the packages. This prompts the following updates:
    • Metrics Exporters to the latest Metrics SDK (exporter-metrics-otlp-grpc, exporter-metrics-otlp-http, exporter-metrics-otlp-proto)
    • Update of opentelemetry-sdk-node to the latest Metrics SDK.
    • Update of otlp-transformer to the latest Metrics SDK.
  • updates the dependencies to stable packages to 1.1.1 which required updates to:

I apologize for this huge PR, it was discussed and it is, unfortunately, necessary. The *-wip packages pulled in 1.0.x, and leaving it out caused the build of this PR (originally only an update to the OTLP Metrics Exporters) to fail (see also: comments on #2874). This was due to their dependency on sdk-trace-base via exporter-trace-otlp-http.

Original Issue #2774
Supersedes #2874

Type of change

  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

  • Updated unit tests

Checklist:

  • Followed the style guidelines of this project
  • Unit tests have been added
  • Documentation has been updated

@pichlermarc pichlermarc changed the title feature(otlp-metrics-exporter): update OTLP metrics exporters to use latest SDK feat(otlp-metrics-exporter): update OTLP metrics exporters to use latest SDK Mar 28, 2022
@codecov
Copy link

codecov bot commented Mar 29, 2022

Codecov Report

Merging #2871 (54a6166) into main (eac583e) will decrease coverage by 1.19%.
The diff coverage is n/a.

❗ Current head 54a6166 differs from pull request most recent head 68f0fef. Consider uploading reports for the commit 68f0fef to get more accurate results

@@            Coverage Diff             @@
##             main    #2871      +/-   ##
==========================================
- Coverage   93.42%   92.22%   -1.20%     
==========================================
  Files         162       68      -94     
  Lines        5564     1993    -3571     
  Branches     1175      435     -740     
==========================================
- Hits         5198     1838    -3360     
+ Misses        366      155     -211     
Impacted Files Coverage Δ
...ckages/opentelemetry-sdk-trace-web/karma.worker.js 0.00% <0.00%> (-100.00%) ⬇️
...s/opentelemetry-core/src/platform/node/sdk-info.ts 0.00% <0.00%> (-100.00%) ⬇️
...opentelemetry-core/src/platform/node/globalThis.ts 0.00% <0.00%> (-100.00%) ⬇️
...pentelemetry-core/src/platform/node/performance.ts 0.00% <0.00%> (-100.00%) ⬇️
...emetry-api-metrics/src/platform/node/globalThis.ts 0.00% <0.00%> (-100.00%) ⬇️
...lemetry-resources/src/detectors/ProcessDetector.ts 31.81% <0.00%> (-68.19%) ⬇️
...ckages/opentelemetry-exporter-zipkin/src/zipkin.ts 84.48% <0.00%> (-15.52%) ⬇️
...lemetry-resources/src/detectors/BrowserDetector.ts 93.33% <0.00%> (-6.67%) ⬇️
...exporter-metrics-otlp-http/src/transformMetrics.ts 91.37% <0.00%> (-4.28%) ⬇️
...s/opentelemetry-instrumentation-fetch/src/fetch.ts 96.53% <0.00%> (-0.48%) ⬇️
... and 99 more

@pichlermarc pichlermarc force-pushed the update-otlp-metric-exporter branch from e373187 to f1ba2fb Compare March 29, 2022 18:55
Copy link
Contributor

@seemk seemk left a comment

Choose a reason for hiding this comment

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

What about the proto transformer package (introduced in #2746)? Should it be used as some of the proto types in this PR are a bit out of date, i.e. intSum and doubleSum metricfields?

@pichlermarc
Copy link
Member Author

What about the proto transformer package (introduced in #2746)? Should it be used as some of the proto types in this PR are a bit out of date, i.e. intSum and doubleSum metricfields?

True. Since we're now dropping the -wip from the package names we'll have to update that package this in this PR anyway. I'm working on that right now 🙂

@pichlermarc pichlermarc force-pushed the update-otlp-metric-exporter branch from 1f9a214 to ff547ff Compare March 31, 2022 12:41
@rauno56
Copy link
Member

rauno56 commented Mar 31, 2022

We later discussed changes in this PR after the official part of the SIG meeting.

To my understanding, updating anything other than devDeps is the way we want to go.

  • devdependencies are mostly pinned and should be updated.
  • Ranges in dependencies and peerDependencies should reflect what's actually required and supported aiming for as broad of an range as possible to allow for maximum npm-deduping and user specification.

The problems(mentioned here) elsewhere were caused by an invalid bump in peerDependency range from >=1.0.0 <1.2.0 to >=1.1.0 <1.2.0.

If we merge this we force the whole userbase(that mainly uses caret-ranges for SDKs) update the API and in turn everything else and run into potential issues with implementing packages that do not support the newest API.

EDIT

Above actually only applies to peer dependency ranges, which, hopefully, only widen from the "top" in the context of one major API version. To conclude, my reconsidered stance is: don't change peer dependency ranges stricter, but updating everything else is fine.

@Flarna
Copy link
Member

Flarna commented Mar 31, 2022

NPM doesn't dedup everything even ranges would allow it. I haven't fully understood this and it depends on the NPM version.
But I think newest NPM version install peer deps automatically and this install process seems to be not fully integrated in the dedup process.

I think the problem is not the API alone.

  • SDK implements API therefore minor API versions are (potentially) breaking for SDK
  • This is very similar for minor SDK versions which may result in breaking e.g. exporters/spanprocessors as they implement the SDK interface

Maybe it's better to create a dedicated issue to discuss and agree an a versioning schema. This PR is already complex enough to get it somewhat running. Tuning the devDeps/Deps ranges in a followup (before release) can be done).

@rauno56
Copy link
Member

rauno56 commented Apr 1, 2022

Sure. Comments are welcome: #2863

@pichlermarc pichlermarc force-pushed the update-otlp-metric-exporter branch from 1c294db to da6e9b3 Compare April 1, 2022 12:44
@pichlermarc
Copy link
Member Author

A quick update on the progress of this PR:
I am now trying to figure out how to get the browser tests for instrumentation-fetch to pass.
I will reset the peer dependencies to what is actually needed by the packages once I am done with this.

Sorry that this is taking so long, most of these packages are new to me.

@pichlermarc pichlermarc force-pushed the update-otlp-metric-exporter branch from a3078b6 to df55205 Compare April 4, 2022 12:52
@pichlermarc pichlermarc changed the title feat(otlp-metrics-exporter): update OTLP metrics exporters to use latest SDK feat(experimental-packages): Update packages to latest SDK Version. Apr 4, 2022
@seemk
Copy link
Contributor

seemk commented Apr 5, 2022

Not related to your changes, but noticed that exporting of createExportMetricsServiceRequest and the metric types are commented out in the transformer package. 👀

@pichlermarc
Copy link
Member Author

Not related to your changes, but noticed that exporting of createExportMetricsServiceRequest and the metric types are commented out in the transformer package. eyes

Yes, I noticed that too. I just talked to @dyladan and am working on a follow-up PR already. To make it easier to change the exporter packages to use the otlp-transformer package individually, we will introduce a otlp-exporter-base package first. This way the metrics exporters do not need to depend on the trace exporters anymore. Then we will update the exporters individually to make reviews easier. 🙂

We could continue the discussion on this in #2774 🙂

@dyladan
Copy link
Member

dyladan commented Apr 5, 2022

Not related to your changes, but noticed that exporting of createExportMetricsServiceRequest and the metric types are commented out in the transformer package. 👀

Yes this was done because the SDK types were still WIP at that time and I wanted to get the package merged with the idea that it could be updated in the future. Now that those types are settled it can be updated and the exports can be added back.

CHANGELOG.md Outdated
@@ -8,6 +8,8 @@ All notable changes to this project will be documented in this file.

### :rocket: (Enhancement)

* [#2871](https://github.com/open-telemetry/opentelemetry-js/pull/2871) feat(experimental-packages): Update packages to latest SDK Version. ([@pichlermarc](https://github.com/pichlermarc))
Copy link
Member

Choose a reason for hiding this comment

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

Can you add sub-bullet points to this? This PR handles a lot more work than what is implied by this title.

Copy link
Member

Choose a reason for hiding this comment

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

We can shorten this entry to be like:

Suggested change
* [#2871](https://github.com/open-telemetry/opentelemetry-js/pull/2871) feat(experimental-packages): Update packages to latest SDK Version. ([@pichlermarc](https://github.com/pichlermarc))
* feat(experimental-packages): Update packages to latest SDK Version. #2871 @pichlermarc

Copy link
Member Author

Choose a reason for hiding this comment

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

@dyladan Good idea, I added sub-bullet points. in ecc38bc.

Copy link
Member

Choose a reason for hiding this comment

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

I've submitted #2889 to discuss the verbose format.

Copy link
Member Author

Choose a reason for hiding this comment

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

@legendecas yes, this seems way more concise, good idea. 🙂 I updated the entry to #2889 format in ab80dba, and moved the entry to the experimental changelog. However, this format does not work for anyone viewing the changelog file locally.

Copy link
Member

@legendecas legendecas left a comment

Choose a reason for hiding this comment

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

Overall LGTM

@dyladan
Copy link
Member

dyladan commented Apr 6, 2022

@open-telemetry/javascript-maintainers I'm going to merge this tomorrow if there are no objections

@dyladan dyladan merged commit 0213d82 into open-telemetry:main Apr 7, 2022
@dyladan dyladan deleted the update-otlp-metric-exporter branch April 7, 2022 20:51
@pichlermarc pichlermarc mentioned this pull request Apr 8, 2022
@@ -316,16 +321,24 @@ export class FetchInstrumentation extends InstrumentationBase<

function endSpanOnSuccess(span: api.Span, response: Response) {
plugin._applyAttributesAfterFetch(span, options, response);
const spanResponse = {
Copy link
Contributor

Choose a reason for hiding this comment

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

Was that meant to be used as a third argument of _endSpan call? Right now the spanResponse variable is unused.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sorry, I did not see your comment on this PR. Looks like this is some leftover from me trying to figure out what eventually turned out to be caused by #2884. I unintentionally added this to commit f6d0b0f.

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.

8 participants