Remove No-Op instrument and Meter creation restrictions (open-telemet…

…ry#3322)

The current No-Op requires all instruments to be created from a Meter
and a Meter to be created from a MeterProvider. This was inherited from
the SDK specification, but it is not necessary. The No-Op performs no
operations and hold no state, therefore creating these objects directly
should not have logical or processing consequences. If there are
consequences of doing this in a language implementation, they are still
permitted to keep this restriction.

This change is desired by the Go SIG. We want to export these No-Op
types so users can create them directly. This will allow them to embed
these No-Op types in their SDKs to define default behaviour, and allow
them to use them directly for testing (instead of having to go through
the creation chain all starting with a MeterProvider).

---------

Co-authored-by: Reiley Yang <[email protected]>
Co-authored-by: Joshua MacDonald <[email protected]>

CHANGELOG.md

@@ -19,6 +19,8 @@ release.
 
 - Clarify that units should use UCUM case sensitive variant.
   ([#3306](https://github.com/open-telemetry/opentelemetry-specification/pull/3306))
+- Remove No-Op instrument and Meter creation requirements.
+  ([#3322](https://github.com/open-telemetry/opentelemetry-specification/pull/3322))
 - Fixed attributes requirement level in semantic conventions for hardware metrics
   ([#3258](https://github.com/open-telemetry/opentelemetry-specification/pull/3258))
 

specification/metrics/noop.md

@@ -82,9 +82,6 @@ any argument it receives.
 
 ## Meter
 
-A Meter is always created by a MeterProvider. The No-Op MUST NOT provide
-a way for a user to create a Meter other than by a No-Op MeterProvider.
-
 The Meters created by the No-Op need to hold as small a memory
 footprint as possible. Therefore, all Meters created MUST NOT hold
 configuration or operational state.
@@ -190,9 +187,6 @@ telemetry.
 
 ### Counter
 
-Counters are always created by a Meter, the No-Op MUST NOT provide a way
-for a user to create a Counter other than by a No-Op Meter.
-
 Counters MUST NOT return a non-empty error or log any message for any
 operations they perform.
 
@@ -206,9 +200,6 @@ state about the arguments it receives.
 
 ### UpDownCounter
 
-UpDownCounters are always created by a Meter, the No-Op MUST NOT provide
-a way for a user to create a UpDownCounter other than by a No-Op Meter.
-
 UpDownCounters MUST NOT return a non-empty error or log any message for
 any operations they perform.
 
@@ -223,9 +214,6 @@ state about the arguments it receives.
 
 ### Histogram
 
-Histograms are always created by a Meter, the No-Op MUST NOT provide a
-way for a user to create a Histogram other than by a No-Op Meter.
-
 Histograms MUST NOT return a non-empty error or log any message for any
 operations they perform.
 
@@ -239,10 +227,6 @@ any state about the arguments it receives.
 
 ### Asynchronous Counter
 
-Asynchronous Counters are always created by a Meter, the No-Op MUST NOT
-provide a way for a user to create a Asynchronous Counter other than by
-a No-Op Meter.
-
 Asynchronous Counters MUST NOT return a non-empty error or log any
 message for any operations they perform.
 
@@ -256,10 +240,6 @@ about observations made for the instrument.
 
 ### Asynchronous UpDownCounter
 
-Asynchronous UpDownCounters are always created by a Meter, the No-Op
-MUST NOT provide a way for a user to create a Asynchronous UpDownCounter
-other than by a No-Op Meter.
-
 Asynchronous UpDownCounters MUST NOT return a non-empty error or log any
 message for any operations they perform.
 
@@ -273,10 +253,6 @@ state about observations made for the instrument.
 
 ### Asynchronous Gauge
 
-Asynchronous Gauges are always created by a Meter, the No-Op MUST NOT
-provide a way for a user to create a Asynchronous Gauge other than by a
-No-Op Meter.
-
 Asynchronous Gauges MUST NOT return a non-empty error or log any message
 for any operations they perform.