Cijo Thomas

> I reckon if we reasonably expect to be able to agree on a suppression mechanism in the future it makes sense to not extend the public API for now,...

https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk.md#meterconfigurator Could the instrumentation's Meter (Scope) name be used to disable it by the end user? (No need of Views) (Agree this is *not* something the instrumentation author can control.)

Removing from 0.28 as option2 is additive change, and can be done post 0.28 as well.

@mohammadVatandoost Thanks! Assigned. To confirm - you'll be pursuing the option2 from the issue, right?

Only providers need option2. **reader**, processor, exporter are not expected to be used outside of providers.

Removing from logging-stable milestone. This is nice-to-have for that milestone, but given this is back-compatible, no need to make it mandatory for the stabilization milestone.

> Only providers need option2. **reader**, processor, exporter are not expected to be used outside of providers. Apologies, I have a correction to make. Though we don't expect users to...

@copilot Please make sure all lint failures are addressed. Running `cargo fmt --all` from the root will address most.

Shows using OTLP with Prometheus (push) https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/metrics/getting-started-prometheus-grafana Shows Prometheus exporter (pull) https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/src/OpenTelemetry.Exporter.Prometheus.AspNetCore

This should be pretty much additive components (new sampler). I don't see any *integration* challenges given these are new components.