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

Mark Metrics SDK as Mixed/Stable #2150

Closed
wants to merge 13 commits into from

Conversation

reyang
Copy link
Member

@reyang reyang commented Nov 23, 2021

This moves the Metrics SDK specification to Mixed/Stable:

  1. Once the spec is marked as "Stable", breaking changes are no longer allowed.
  2. Additive changes are allowed.

These are the issues that should be resolved before we could merge this PR, unless the issue is specific about things that are not marked as Stable in this PR (e.g. Exemplar):
https://github.com/open-telemetry/opentelemetry-specification/issues?q=is%3Aissue+is%3Aopen+label%3Aspec%3Ametrics+label%3Aarea%3Asdk+label%3Arelease%3Arequired-for-ga+-label%3Aarea%3Asemantic-conventions+

Project board https://github.com/orgs/open-telemetry/projects/9.

image
(original link)

@reyang reyang marked this pull request as ready for review November 23, 2021 06:21
@reyang reyang requested review from a team November 23, 2021 06:21
@reyang reyang added spec:metrics Related to the specification/metrics directory area:sdk Related to the SDK labels Nov 23, 2021
@reyang reyang added the release:required-for-ga Must be resolved before GA release, or nice to have before GA label Nov 23, 2021
@reyang reyang added this to the Metrics API/SDK Stable Release milestone Nov 23, 2021
Copy link
Contributor

@MrAlias MrAlias left a comment

Choose a reason for hiding this comment

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

I am not able to approve this as the Go implementation is still being built.

@tigrannajaryan
Copy link
Member

I am not able to approve this as the Go implementation is still being built.

I believe this change says the SDK spec is stable. It does not mean that the SDK implementations are stable.

@MrAlias
Copy link
Contributor

MrAlias commented Nov 24, 2021

I am not able to approve this as the Go implementation is still being built.

I believe this change says the SDK spec is stable. It does not mean that the SDK implementations are stable.

Right, sorry, I wasn't clear. Without an implementation it is hard to say if this specification should be marked stable, specifically from the Go SIGs perspective. There are possibilities that parts of the specification are not implementable in the Go implementation. If that is the case there may need to be modifications that would not be compliant with our stability guarantee.

@carlosalberto
Copy link
Contributor

@jmacd you have been prototyping something for Go, right?

@anuraaga
Copy link
Contributor

There are a couple of TODOs in sdk.md they make the file "feel" not stable - perhaps they should be moved to issues and removed?

@reyang
Copy link
Member Author

reyang commented Nov 24, 2021

There are a couple of TODOs in sdk.md they make the file "feel" not stable - perhaps they should be moved to issues and removed?

There are two places where we have TODOs, and both of them are post-Stable topics (and have issues tracking them).

It seems to be an okay practice? - we've discussed this in the previous Metrics SIG meeting and actually confirmed that the Stable tracing spec also has TODOs.

I'm fine with removing these TODOs if most folks think it'll help to create more clarity.

@reyang
Copy link
Member Author

reyang commented Nov 24, 2021

I am not able to approve this as the Go implementation is still being built.

I believe this change says the SDK spec is stable. It does not mean that the SDK implementations are stable.

Right, sorry, I wasn't clear. Without an implementation it is hard to say if this specification should be marked stable, specifically from the Go SIGs perspective. There are possibilities that parts of the specification are not implementable in the Go implementation. If that is the case there may need to be modifications that would not be compliant with our stability guarantee.

We've discussed this in the previous Spec SIG meeting (several weeks before we marked the Metrics API spec as Stable). In order to mark the Metrics SDK spec as Stable, the following things are required:

  1. All the issues that are tagged as area:sdk + spec:metrics + release:required-for-ga are resolved.
  2. The Metrics SIG has a good confidence that the spec won't have breaking changes.
  3. There are multiple (e.g. 3) language SIGs which are able to follow the spec and implement the metrics SDK.

These are non-goal for Stable:

  1. All languages SIGs could finish the implementation.
  2. All the clarification questions are answered. Many of them are nice-to-have and can be post Stable (e.g. area:allowed-for-ga or area:after-ga or editorial).

@reyang reyang changed the title Mark Metrics SDK as Stable Mark Metrics SDK as Mixed/Stable Nov 29, 2021
specification/metrics/sdk.md Outdated Show resolved Hide resolved
Copy link
Member

@cijothomas cijothomas left a comment

Choose a reason for hiding this comment

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

LGTM.

@cijothomas
Copy link
Member

The data model and proto are stable already, so can we also mark the exporters , except Prometheus, (i.e OTLP , stdout, inmemory) as stable as well? (separate topic, but related, hence mentioning it here.)

@reyang
Copy link
Member Author

reyang commented Nov 29, 2021

The data model and proto are stable already, so can we also mark the exporters , except Prometheus, (i.e OTLP , stdout, inmemory) as stable as well? (separate topic, but related, hence mentioning it here.)

#2175

@carlosalberto
Copy link
Contributor

Sounds like a good trade off going forward!

Copy link
Contributor

@jmacd jmacd left a comment

Choose a reason for hiding this comment

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

I propose several components remain in Feature-freeze. This topic was discussed by the technical committee today and the consensus is that we believe the specification is practically Stable, but that an uninitiated member of the community could probably not implement it from scratch in a way that conforms with our group understanding.

We expect to do a bit of editorial work on this specification as the next 1 or 2 prototypes are completed, and then we can finish marking this Stable.

@@ -47,6 +47,8 @@

## MeterProvider

**Status**: [Stable](../document-status.md)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
**Status**: [Stable](../document-status.md)
**Status**: [Feature-freeze](../document-status.md)

@@ -554,6 +562,8 @@ measurements using the equivalent of the following naive algorithm:

## MetricReader

**Status**: [Stable](../document-status.md)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
**Status**: [Stable](../document-status.md)
**Status**: [Feature-freeze](../document-status.md)

@@ -661,6 +671,8 @@ Configurable parameters:

## MetricExporter

**Status**: [Stable](../document-status.md)
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
**Status**: [Stable](../document-status.md)
**Status**: [Feature-freeze](../document-status.md)

Copy link
Contributor

@jmacd jmacd left a comment

Choose a reason for hiding this comment

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

@open-telemetry/technical-committee as discussed I think we can merge this PR after accepting the three changes proposed by me.

@jmacd
Copy link
Contributor

jmacd commented Dec 1, 2021

@cijothomas please take a look at my proposal for merging this PR.

@cijothomas
Copy link
Member

@cijothomas please take a look at my proposal for merging this PR.

This comment was calling out that, the Exporter section of the SDK spec is not stable, so the exporters themselves (OTLP/Stdout/InMemory), should not be marked stable.

@jmacd
Copy link
Contributor

jmacd commented Dec 1, 2021

Exporter section of the SDK spec is not stable, so the exporters themselves (OTLP/Stdout/InMemory), should not be marked stable.

I'm not sure I agree -- can't a specific exporter specification be stable even if the general interface specification is not? For components of an SDK I see this dependency being real (i.e., an SDK exporter can't be stable of other components it depends on are not stable), but for a specification I don't see a hard connection there.

E.g., the stderr exporter says the "StderrExporter is an Exporter". This is true and stable and will not change even if we change the specification for Exporter, right?

Copy link
Contributor

@jmacd jmacd left a comment

Choose a reason for hiding this comment

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

With the suggestion to leave MeterProvider in Feature-freeze, these two sections are redundant.

* The `extra dimensions` which come from Baggage/Context (optional). If not
provided, no extra dimension will be used. Please note that this only
applies to [synchronous Instruments](./api.md#synchronous-instrument).
* **Status**: [Feature-freeze](../document-status.md) - the `extra dimensions`
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* **Status**: [Feature-freeze](../document-status.md) - the `extra dimensions`
* the `extra dimensions`

* The `exemplar_reservoir` (optional) to use for storing exemplars.
This should be a factory or callback similar to aggregation which allows
different reservoirs to be chosen by the aggregation.
* **Status**: [Feature-freeze](../document-status.md) - the
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
* **Status**: [Feature-freeze](../document-status.md) - the
* the

@github-actions
Copy link

github-actions bot commented Dec 9, 2021

This PR was marked stale due to lack of activity. It will be closed in 7 days.

@github-actions
Copy link

Closed as inactive. Feel free to reopen if this PR is still being worked on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:sdk Related to the SDK release:required-for-ga Must be resolved before GA release, or nice to have before GA spec:metrics Related to the specification/metrics directory Stale
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants