chore: v1.0.0 proposal #2468

dyladan · 2021-09-13T13:04:33Z

There are no changes from 0.26.0

Huge thank you to all involved who helped get us this far! 🎉

@aabmass
@adamegyed
@alisabzevari
@amanbrar1999
@AndrewGrachov
@antoniomrfranco
@anuraaga
@aphelionz
@aravinsiva
@Asafb26
@astorm
@austinlparker
@banothurameshnaik
@blumamir
@bradfrosty
@brunoluiz
@carolinee21
@chalin
@confiq
@connorlindsey
@CptSchnitz
@danielmbarlow
@DarkPurple141
@davidwitten
@debagger
@dengliming
@dobesv
@drexler
@dyladan
@echoontheway
@EdZou
@flands
@Flarna
@hermanbanken
@hongbo
@ivansenic
@JamesJHPark
@JapuDCret
@jessitron
@johanneswuerbach
@johnbley
@jonahrosenblum
@jonchurch
@jordanworner
@jtmalinowski
@jufab
@justinwalz
@kanikashah90
@KKelvinLo
@kkruk
@kudlatyamroth
@legendecas
@leonardodalcin
@lizthegrey
@lonewolf3739
@longility
@luebken
@lykkin
@marcbachmann
@MarkSeufert
@markwolff
@mayurkale22
@mhennoch
@michaelgoin
@mihirsoni
@morigs
@mottibec
@MSNev
@mustafain117
@mwear
@mzahor
@naseemkullah
@NathanielRN
@neilfordyce
@nflaig
@niekert
@nijotz
@niko
@nirsky
@nozik
@nvenegas
@obecny
@OlivierAlbertini
@OmkarKirpan
@pauldraper
@paulfairless
@PaurushGarg
@philipszalla
@pokutuna
@pragmaticivan
@pramodsreek
@quickgiant
@Rauno56
@reggiemcdonald
@renovate
@rezakrimi
@rubenvp8510
@ryhinchey
@sbrichardson
@seemk
@sergeylanzman
@sergioregueira
@sfishel
@shivkanya9146
@shovnik
@sid
@skjindal93
@sleighzy
@snyder114
@srjames90
@svrnm
@t2t2
@tannaga
@thgao
@thisthat
@TigerHe7
@TsvetanMilanov
@vknelluri
@vmarchaud
@vreynolds
@weyert
@YanivD
@zoomchan

codecov · 2021-09-13T13:06:30Z

Codecov Report

Merging #2468 (c28965a) into main (6afe2fc) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main    #2468   +/-   ##
=======================================
  Coverage   93.23%   93.23%           
=======================================
  Files         137      137           
  Lines        5042     5042           
  Branches     1066     1066           
=======================================
  Hits         4701     4701           
  Misses        341      341

vmarchaud · 2021-09-13T13:16:22Z

The only major caveat I see is that the collector exporter depends on the experimental metrics package, but that is probably ok.

I'm fine with it, at the end of the line that means we'll have to bump major when the metrics api will be merged with the API pkg.

Also there were discussing about renaming the exporter collector, do we want to do this before 1.0 ? #2364

packages/opentelemetry-core/package.json

packages/opentelemetry-sdk-node/package.json

dyladan · 2021-09-13T18:38:36Z

@open-telemetry/javascript-maintainers @open-telemetry/javascript-approvers I'm thinking we should probably hold back sdk-node as experimental until we can remove its dependence upon experimental and contrib packages. WDYT?

willarmiros · 2021-09-13T18:55:39Z

@open-telemetry/javascript-maintainers @open-telemetry/javascript-approvers I'm thinking we should probably hold back sdk-node as experimental until we can remove its dependence upon experimental and contrib packages. WDYT?

Just to confirm, @opentelemetry/sdk-trace-node would still be 1.0? If so that makes sense to me.

dyladan · 2021-09-13T19:20:16Z

@open-telemetry/javascript-maintainers @open-telemetry/javascript-approvers I'm thinking we should probably hold back sdk-node as experimental until we can remove its dependence upon experimental and contrib packages. WDYT?

Just to confirm, @opentelemetry/sdk-trace-node would still be 1.0? If so that makes sense to me.

yes

dyladan · 2021-09-14T20:01:24Z

Updated to put sdk-node in experimental which will give us time to asses its dependencies and public interface.

vmarchaud · 2021-09-15T07:55:53Z

What do we do about #2364 ? That would be preferable to do it now before 1.0 wdyt ?

dyladan · 2021-09-15T15:56:52Z

What do we do about #2364 ? That would be preferable to do it now before 1.0 wdyt ?

Created a PR #2476

CHANGELOG.md

willarmiros

Looks good to me!

vmarchaud

finally 🚀

obecny · 2021-09-16T16:10:39Z

exporter collector can exports traces and metrics, metrics are experimental, not sure though what we should be doing with this than, Should we leave it, move exporters to experimental or split it etc. or something else ?

willarmiros · 2021-09-16T18:43:00Z

@obecny yeah that was the other issue that Dan called out in the description. Some SIGs like Python and .NET have went ahead and marked their exporters as stable.

But we could move them into separate packages with traces in stable and metrics in experimental if we wanted to avoid possible major version bumps. Do you know how much work that would be?

legendecas · 2021-09-17T09:54:53Z

As @opentelemetry/api-metrics is not stable yet, I'm wondering how would it be meaningful to mark @opentelemetry/exporter-prometheus as stable? It's not like @opentelemetry/exporter-collector-* that export traces, exporter-prometheus only export metrics.

obecny · 2021-09-17T11:19:41Z

@obecny yeah that was the other issue that Dan called out in the description. Some SIGs like Python and .NET have went ahead and marked their exporters as stable.

But we could move them into separate packages with traces in stable and metrics in experimental if we wanted to avoid possible major version bumps. Do you know how much work that would be?

quite a lot of work tbh

aabmass · 2021-09-17T16:10:51Z

@opentelemetry/exporter-collector-* depends on @opentelemetry/sdk-metric-base

This is probably OK, but if the metric export interface changes it will require a major version bump of the exporter

In Python, we removed the OTLP metrics exporter altogether. The metrics spec has changed so much we decided we would need to reimplement it anyway.

However, since JS has separated the metrics and trace api/sdk altogether, it seems reasonable to separate the trace and metric OTLP exporters.

willarmiros · 2021-09-17T16:41:36Z

As @opentelemetry/api-metrics is not stable yet, I'm wondering how would it be meaningful to mark @opentelemetry/exporter-prometheus as stable? It's not like @opentelemetry/exporter-collector-* that export traces, exporter-prometheus only export metrics.

I agree, Prometheus exporter should stay in experimental.

quite a lot of work tbh

So it seems like this would require splitting the existing 3 OTLP exporters (@opentelemetry/exporter-otlp-http, @opentelemetry/exporter-otlp-grpc, and @opentelemetry/exporter-otlp-proto) into 9 distinct packages if we wanted to do this correctly/in line with the pattern of other components:

Move the OTLPTraceExporter classes (and transform file for HTTP exporter) into new packages called @opentelemetry/exporter-trace-otlp-*. These packages will be marked as stable.
Move the OTLPMetricExporter classes (and transformMetrics file for HTTP exporter) into new packages called @opentelemetry/exporter-metric-otlp-*. These packages will be marked as experimental.
Remove dependencies on metrics & traces SDKs/APIs from original exporter packages. They can now be released as stable.
(optional) rename the existing exporter packages, to @opentelemetry/exporter-base-otlp-* (or leave as is for simplicity).

@open-telemetry/javascript-approvers What do you think of the approach and package naming in this proposal? If we're agreed this is something we should do before 1.0.0 I feel like this would be only slightly more work than #2476.

legendecas · 2021-09-17T17:02:27Z

I would vote for separating tracing and metrics collection for OTLP exporter and put them on different stage as metrics spec has changed so much since then.

obecny · 2021-09-17T17:24:47Z

As @opentelemetry/api-metrics is not stable yet, I'm wondering how would it be meaningful to mark @opentelemetry/exporter-prometheus as stable? It's not like @opentelemetry/exporter-collector-* that export traces, exporter-prometheus only export metrics.

I agree, Prometheus exporter should stay in experimental.

quite a lot of work tbh

So it seems like this would require splitting the existing 3 OTLP exporters (@opentelemetry/exporter-otlp-http, @opentelemetry/exporter-otlp-grpc, and @opentelemetry/exporter-otlp-proto) into 9 distinct packages if we wanted to do this correctly/in line with the pattern of other components:

Move the OTLPTraceExporter classes (and transform file for HTTP exporter) into new packages called @opentelemetry/exporter-trace-otlp-*. These packages will be marked as stable.

Move the OTLPMetricExporter classes (and transformMetrics file for HTTP exporter) into new packages called @opentelemetry/exporter-metric-otlp-*. These packages will be marked as experimental.

Remove dependencies on metrics & traces SDKs/APIs from original exporter packages. They can now be released as stable.

(optional) rename the existing exporter packages, to @opentelemetry/exporter-base-otlp-* (or leave as is for simplicity).

@open-telemetry/javascript-approvers What do you think of the approach and package naming in this proposal? If we're agreed this is something we should do before 1.0.0 I feel like this would be only slightly more work than #2476.

how did you count 9 ? it would be 6 exporters, metrics inherits from tracing this is how it is built the difference is in transport layer and data conversion

willarmiros · 2021-09-17T17:30:56Z

how did you count 9 ? it would be 6 exporters, metrics inherits from tracing this is how it is built the difference is in transport layer and data conversion

Ah yes that makes sense. I thought for each protocol we would have a "base" exporter, then trace-specific logic would be in a separate package, and metric-specific logic in yet another. So 3 packages * 3 protocols = 9.

But if we're leaving the trace logic in the existing exporter and just creating a new package for metric exporters, then that's easier and simpler. We can leave the exporter package names as-is. Do you agree with the naming of @opentelemetry/exporter-metric-otlp-* for the new ones?

I unfortunately don't have time to work on this today, but if anyone else could take it up that'd be awesome. Otherwise maybe myself or @dyladan could have time next week.

vmarchaud · 2021-09-18T19:41:55Z

I would like to add that when logs spec will be done, it might be easier to have them as a seperate experimental exporter. Could we maybe let the exporter still be experimental for now while we make the effort to split metrics out ? So we can still GA SDKs (which i believe is the main goal here)

dyladan · 2021-09-20T12:58:17Z

I like the idea of having a separate exporter package for each signal. Ideally I think the metrics would not depend on the trace exporter, but that's an internal change that can be made after 1.0

dyladan · 2021-09-20T12:58:54Z

@aabmass are you volunteering to take on that project?

willarmiros · 2021-09-20T16:54:58Z

@dyladan I'm not sure if you meant to tag me there but yes I can take a stab at this later today. I'll take the approach with 6 total packages (where the metric exporters depend on the trace exporters) unless anyone thinks otherwise.

dyladan · 2021-09-20T17:39:33Z

I'm not sure what made me tag Aaron oops. I probably meant to tag you :)

dyladan · 2021-09-20T17:40:45Z

I'll take the approach with 6 total packages (where the metric exporters depend on the trace exporters) unless anyone thinks otherwise.

This seems reasonable. As a follow-up we can factor out the shared parts into a base package if that makes sense later. It can be done after 1.0 since I wouldn't expect that to be a breaking change.

obecny · 2021-09-21T00:29:37Z

I will refactor this, but I think we should move otlp exporters to experimental package first

willarmiros · 2021-09-21T10:34:29Z

Sorry all, still working on this. I will have something out by later tomorrow. The tricky bit is that due to the repo splitting, we cannot depend directly on the trace/base exporters from the metric exporters after they're moved to experimental. So I've done pretty much all of the work of separating them, but now I still need to verify the metric exporters will work without having to make any breaking changes to the base exporter after releasing it.

rauno56 · 2021-09-21T11:02:56Z

Do you think we could release this as 0.x instead for now?
It would be of great value to get the changes listed here public and make the actual 1.0 release "less grand".

willarmiros · 2021-09-22T09:42:33Z

Went ahead and opened #2486 to continue discussion on separating exporters. We can leave this PR to discuss 1.0.0 release.

willarmiros · 2021-09-27T15:34:54Z

Per discussion in SIG this is now only blocked on #2490.

dyladan · 2021-09-30T13:10:54Z

Updated and ready for ✔️

vmarchaud

🎊

johnbley

🎉

dyladan requested a review from a team September 13, 2021 13:04

dyladan force-pushed the proposal-1.0 branch from b5b2f6f to 0099650 Compare September 13, 2021 15:18

MSNev reviewed Sep 13, 2021

View reviewed changes

packages/opentelemetry-core/package.json Outdated Show resolved Hide resolved

Flarna reviewed Sep 13, 2021

View reviewed changes

packages/opentelemetry-sdk-node/package.json Outdated Show resolved Hide resolved

Flarna reviewed Sep 13, 2021

View reviewed changes

packages/opentelemetry-sdk-node/package.json Outdated Show resolved Hide resolved

dyladan force-pushed the proposal-1.0 branch from e40da37 to 6a7c6fa Compare September 14, 2021 18:57

dyladan force-pushed the proposal-1.0 branch from 6a7c6fa to 37ec96d Compare September 15, 2021 18:50

vmarchaud reviewed Sep 15, 2021

View reviewed changes

CHANGELOG.md Show resolved Hide resolved

willarmiros approved these changes Sep 15, 2021

View reviewed changes

vmarchaud approved these changes Sep 16, 2021

View reviewed changes

vmarchaud self-requested a review September 18, 2021 19:39

This was referenced Sep 22, 2021

feat!: Split metric and trace exporters into new experimental packages #2485

Merged

Remove metrics exporters before declaring OTLP exporters stable #2486

Closed

rauno56 mentioned this pull request Sep 28, 2021

GA request for signalfx / splunk-otel-js signalfx/gdi-specification#126

Closed

chore: v1.0.0 proposal

7adfb13

dyladan force-pushed the proposal-1.0 branch from d5fecea to 7adfb13 Compare September 30, 2021 13:10

vmarchaud approved these changes Sep 30, 2021

View reviewed changes

johnbley approved these changes Sep 30, 2021

View reviewed changes

weyert approved these changes Sep 30, 2021

View reviewed changes

MSNev approved these changes Sep 30, 2021

View reviewed changes

Merge branch 'main' into proposal-1.0

c28965a

dyladan merged commit 69b925d into open-telemetry:main Sep 30, 2021

dyladan deleted the proposal-1.0 branch September 30, 2021 20:40

vmarchaud added the internal label Oct 1, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore: v1.0.0 proposal #2468

chore: v1.0.0 proposal #2468

dyladan commented Sep 13, 2021 •

edited

Loading

codecov bot commented Sep 13, 2021 •

edited

Loading

vmarchaud commented Sep 13, 2021

dyladan commented Sep 13, 2021

willarmiros commented Sep 13, 2021

dyladan commented Sep 13, 2021

dyladan commented Sep 14, 2021

vmarchaud commented Sep 15, 2021

dyladan commented Sep 15, 2021

willarmiros left a comment

vmarchaud left a comment •

edited

Loading

obecny commented Sep 16, 2021

willarmiros commented Sep 16, 2021

legendecas commented Sep 17, 2021

obecny commented Sep 17, 2021

aabmass commented Sep 17, 2021

willarmiros commented Sep 17, 2021

legendecas commented Sep 17, 2021 •

edited

Loading

obecny commented Sep 17, 2021

willarmiros commented Sep 17, 2021

vmarchaud commented Sep 18, 2021

dyladan commented Sep 20, 2021

dyladan commented Sep 20, 2021

willarmiros commented Sep 20, 2021

dyladan commented Sep 20, 2021

dyladan commented Sep 20, 2021

obecny commented Sep 21, 2021

willarmiros commented Sep 21, 2021

rauno56 commented Sep 21, 2021

willarmiros commented Sep 22, 2021

willarmiros commented Sep 27, 2021

dyladan commented Sep 30, 2021

vmarchaud left a comment

johnbley left a comment

chore: v1.0.0 proposal #2468

chore: v1.0.0 proposal #2468

Conversation

dyladan commented Sep 13, 2021 • edited Loading

codecov bot commented Sep 13, 2021 • edited Loading

Codecov Report

vmarchaud commented Sep 13, 2021

dyladan commented Sep 13, 2021

willarmiros commented Sep 13, 2021

dyladan commented Sep 13, 2021

dyladan commented Sep 14, 2021

vmarchaud commented Sep 15, 2021

dyladan commented Sep 15, 2021

willarmiros left a comment

Choose a reason for hiding this comment

vmarchaud left a comment • edited Loading

Choose a reason for hiding this comment

obecny commented Sep 16, 2021

willarmiros commented Sep 16, 2021

legendecas commented Sep 17, 2021

obecny commented Sep 17, 2021

aabmass commented Sep 17, 2021

willarmiros commented Sep 17, 2021

legendecas commented Sep 17, 2021 • edited Loading

obecny commented Sep 17, 2021

willarmiros commented Sep 17, 2021

vmarchaud commented Sep 18, 2021

dyladan commented Sep 20, 2021

dyladan commented Sep 20, 2021

willarmiros commented Sep 20, 2021

dyladan commented Sep 20, 2021

dyladan commented Sep 20, 2021

obecny commented Sep 21, 2021

willarmiros commented Sep 21, 2021

rauno56 commented Sep 21, 2021

willarmiros commented Sep 22, 2021

willarmiros commented Sep 27, 2021

dyladan commented Sep 30, 2021

vmarchaud left a comment

Choose a reason for hiding this comment

johnbley left a comment

Choose a reason for hiding this comment

dyladan commented Sep 13, 2021 •

edited

Loading

codecov bot commented Sep 13, 2021 •

edited

Loading

vmarchaud left a comment •

edited

Loading

legendecas commented Sep 17, 2021 •

edited

Loading