From d75a7bc5bc7149765b9d75dad1e11949d946e6ac Mon Sep 17 00:00:00 2001 From: Bogdan Drutu Date: Mon, 12 Sep 2022 15:57:45 -0700 Subject: [PATCH] Remove scope attributes form the Scope identity Fixes https://github.com/open-telemetry/opentelemetry-specification/issues/2762 The identity part can be changed later if the community agrees to accept this change, but to be safe for the moment revert this change. Signed-off-by: Bogdan Drutu --- specification/metrics/api.md | 22 ++++++++-------------- specification/trace/api.md | 24 ++++++++++++++---------- 2 files changed, 22 insertions(+), 24 deletions(-) diff --git a/specification/metrics/api.md b/specification/metrics/api.md index af32b8f7683..e2fdb44e8ab 100644 --- a/specification/metrics/api.md +++ b/specification/metrics/api.md @@ -147,20 +147,14 @@ This API MUST accept the following parameters: * [since 1.13.0] `attributes` (optional): Specifies the instrumentation scope attributes to associate with emitted telemetry. -Meters are identified by all of these parameters. - -Implementations MUST return different `Meter` instances when called repeatedly -with different values of parameters. Note that always returning a new `Meter` instance -is a valid implementation. The only exception to this rule is the no-op `Meter`: -implementations MAY return the same instance regardless of parameter values. - -It is unspecified whether or under which conditions the same or different -`Meter` instances are returned from this function when the same -(name,version,schema_url,attributes) parameters are used. - -The term *identical* applied to Meters describes instances where all identifying fields -are equal. The term *distinct* applied to Meters describes instances where at -least one identifying field has a different value. +Meters are identified by name, version, and schema_url fields. When more than one +Meter of the same `name`, `version`, and `schema_url` is created, it +is unspecified whether or under which conditions the same or different +`Meter` instances are returned. + +The term *identical* applied to Meters describes instances where all identifying +fields are equal. The term *distinct* applied to Meters describes instances where +at least one identifying field has a different value. Implementations MUST NOT require users to repeatedly obtain a `Meter` with the same identity to pick up configuration changes. This can be diff --git a/specification/trace/api.md b/specification/trace/api.md index 6ef87958cae..184668a31df 100644 --- a/specification/trace/api.md +++ b/specification/trace/api.md @@ -131,23 +131,27 @@ This API MUST accept the following parameters: - [since 1.13.0] `attributes` (optional): Specifies the instrumentation scope attributes to associate with emitted telemetry. -Implementations MUST return different `Tracer` instances when called repeatedly -with different values of parameters. Note that always returning a new `Tracer` instance -is a valid implementation. The only exception to this rule is the no-op `Tracer`: -implementations MAY return the same instance regardless of parameter values. +Tracers are identified by name, version, and schema_url fields. When more than one +Tracer of the same `name`, `version`, and `schema_url` is created, it +is unspecified whether or under which conditions the same or different +`Tracer` instances are returned. + +The term *identical* applied to Tracers describes instances where all identifying +fields are equal. The term *distinct* applied to Tracers describes instances where at +least one identifying field has a different value. Implementations MUST NOT require users to repeatedly obtain a `Tracer` again -with the same name+version+schema_url+attributes to pick up configuration changes. -This can be achieved either by allowing to work with an outdated configuration or -by ensuring that new configuration applies also to previously returned `Tracer`s. +with the same identity to pick up configuration changes. This can be +achieved either by allowing to work with an outdated configuration or by +ensuring that new configuration applies also to previously returned `Tracer`s. Note: This could, for example, be implemented by storing any mutable configuration in the `TracerProvider` and having `Tracer` implementation objects have a reference to the `TracerProvider` from which they were obtained. If configuration must be stored per-tracer (such as disabling a certain tracer), -the tracer could, for example, do a look-up with its name+version+schema_url+attributes in -a map in the `TracerProvider`, or the `TracerProvider` could maintain a registry -of all returned `Tracer`s and actively update their configuration if it changes. +the tracer could, for example, do a look-up with its identity in a map +in the `TracerProvider`, or the `TracerProvider` could maintain a registry of +all returned `Tracer`s and actively update their configuration if it changes. The effect of associating a Schema URL with a `Tracer` MUST be that the telemetry emitted using the `Tracer` will be associated with the Schema URL,