[Metrics API] Mark NoopMeterProvider as pub(crate)

[utpilla]

Changes

• NoopMeterProvider is only used in the API project

Please provide a brief description of the changes here.

Merge requirement checklist

• CONTRIBUTING guidelines followed
• Unit tests added/updated (if applicable)
• Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
• Changes in public API reviewed (if applicable)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 79.2%. Comparing base (78a684c) to head (af5084f).
Report is 1 commits behind head on main.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #2191   +/-   ##
=====================================
  Coverage   79.2%   79.2%           
=====================================
  Files        121     121           
  Lines      20870   20870           
=====================================
  Hits       16534   16534           
  Misses      4336    4336           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cijothomas]

changelog as this is removing existing public api though this should affect noone?

[lalitb]

Just confirm if this is specs compliant - https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/noop.md, as per the specs - "All language implementations of OpenTelemetry MUST provide a No-Op."

[cijothomas]

Just confirm if this is specs compliant - https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/noop.md, as per the specs - "All language implementations of OpenTelemetry MUST provide a No-Op."

This is spec compliant. We have no-op behavior, just not exposing them to public.

[lalitb]

This is spec compliant. We have no-op behavior, just not exposing them to public.

What if the user wants to explicitly set the no-op provider, to (say) disable the telemetry? As per the specs, the noop is for end-user.

[cijothomas]

This is spec compliant. We have no-op behavior, just not exposing them to public.

What if the user wants to explicitly set the no-op provider, to (say) disable the telemetry? As per the specs, the noop is for end-user.

If there is a need for that, we can offer mechanisms to achieve that.
(Tracing spec does not have the equivalent part in the spec like Metrics)

[phillipleblanc]

Can we make this public again? I was depending on this to disable telemetry selectively. cc @cijothomas

[lalitb]

Can we make this public again? I was depending on this to disable telemetry selectively. cc @cijothomas

@phillipleblanc Not directly answering comment, even though I voted above to keep the API. But just to say "Hi" - Not sure you remember, but we worked together in App Center (VSAC) in Microsoft :)

[phillipleblanc]

Hey, yep I remember! Small world :)

[lalitb]

Can we make this public again? I was depending on this to disable telemetry selectively. cc @cijothomas

back to the query, if you would like to use NoopMeterProvider to disable telemetry, you can save the handle initially at startup as dyn provider, and use it later when required. To demonstrate this (refer the use of wrapped_noop_provider):
https://github.com/open-telemetry/opentelemetry-rust/compare/main...lalitb:use-noop-provider?expand=1

[phillipleblanc]

I ended up copying the implementation of NoopMeterProvider into my project, which is also what tracing-opentelemetry did: tokio-rs/tracing-opentelemetry#184 (comment)

[cijothomas]

Can we make this public again? I was depending on this to disable telemetry selectively. cc @cijothomas

Could you open a new issue for this, so we can track accordingly?

[phillipleblanc]

Filed! #2444