-
Notifications
You must be signed in to change notification settings - Fork 894
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
What should be the schema URL merge behavior when a resource is empty (no attributes) #3710
Comments
In my opinion the currently defined behavior is fine. Otherwise you'd get into situations where setting or unsetting an environment variable causes or resolves resource merging errors, which is quite unexpected. |
@pyohannes But it's also the current behavior today, no? By setting the schemaURL from an empty resource, we may be affecting the other resource attribute's value if a transformation happen, no? |
Well, I'd say that's more a problem of having schema-sensitive resources without specified schema. From the spec:
|
This seems like the desirable behavior to me. The updating resource's schemaUrl is explicitly provided and I would expect it become the schemaUrl of the resulting resource. |
I guess that's fair. What I was thinking is: Let's say I have a resource detector that contains some attributes that happen to follow the OTel semconv, but also it contains other, unrelated attributes. By following the spec, that resource detector should not populate the schema url, as it contains things that are not in the semconv. But: by getting the Schema URL of the updating resource (and empty), my old resource is now bound to it, and may change because of transformations. If that's intended then we are fine, but I wanted to see if everyone agrees. |
This is a proposal to address Resource and Entity data model interactions, including a path forward to address immediate friction and issues in the current resource specification. The proposal includes all links and context needed to justify it, but duplicating a snapshot here: ## Motivation This proposal attempts to focus on the following problems within OpenTelemetry to unblock multiple working groups: - Allowing mutating attributes to participate in Resource ([OTEP 208](#208)). - Allow Resource to handle entities whose lifetimes don't match the SDK's lifetime ([OTEP 208](#208)). - Provide support for async resource lookup ([spec#952](open-telemetry/opentelemetry-specification#952)). - Fix current Resource merge rules in the specification, which most implementations violate ([oteps#208](#208), [spec#3382](open-telemetry/opentelemetry-specification#3382), [spec#3710](open-telemetry/opentelemetry-specification#3710)). - Allow semantic convention resource modeling to progress ([spec#605](open-telemetry/opentelemetry-specification#605), [spec#559](open-telemetry/opentelemetry-specification#559), etc). --------- Co-authored-by: Tigran Najaryan <[email protected]> Co-authored-by: jack-berg <[email protected]> Co-authored-by: Arve Knudsen <[email protected]> Co-authored-by: David Ashpole <[email protected]>
This is a proposal to address Resource and Entity data model interactions, including a path forward to address immediate friction and issues in the current resource specification. The proposal includes all links and context needed to justify it, but duplicating a snapshot here: ## Motivation This proposal attempts to focus on the following problems within OpenTelemetry to unblock multiple working groups: - Allowing mutating attributes to participate in Resource ([OTEP 208](open-telemetry/oteps#208)). - Allow Resource to handle entities whose lifetimes don't match the SDK's lifetime ([OTEP 208](open-telemetry/oteps#208)). - Provide support for async resource lookup ([spec#952](open-telemetry#952)). - Fix current Resource merge rules in the specification, which most implementations violate ([oteps#208](open-telemetry/oteps#208), [spec#3382](open-telemetry#3382), [spec#3710](open-telemetry#3710)). - Allow semantic convention resource modeling to progress ([spec#605](open-telemetry#605), [spec#559](open-telemetry#559), etc). --------- Co-authored-by: Tigran Najaryan <[email protected]> Co-authored-by: jack-berg <[email protected]> Co-authored-by: Arve Knudsen <[email protected]> Co-authored-by: David Ashpole <[email protected]>
This is a proposal to address Resource and Entity data model interactions, including a path forward to address immediate friction and issues in the current resource specification. The proposal includes all links and context needed to justify it, but duplicating a snapshot here: ## Motivation This proposal attempts to focus on the following problems within OpenTelemetry to unblock multiple working groups: - Allowing mutating attributes to participate in Resource ([OTEP 208](open-telemetry#208)). - Allow Resource to handle entities whose lifetimes don't match the SDK's lifetime ([OTEP 208](open-telemetry#208)). - Provide support for async resource lookup ([spec#952](open-telemetry/opentelemetry-specification#952)). - Fix current Resource merge rules in the specification, which most implementations violate ([oteps#208](open-telemetry#208), [spec#3382](open-telemetry/opentelemetry-specification#3382), [spec#3710](open-telemetry/opentelemetry-specification#3710)). - Allow semantic convention resource modeling to progress ([spec#605](open-telemetry/opentelemetry-specification#605), [spec#559](open-telemetry/opentelemetry-specification#559), etc). --------- Co-authored-by: Tigran Najaryan <[email protected]> Co-authored-by: jack-berg <[email protected]> Co-authored-by: Arve Knudsen <[email protected]> Co-authored-by: David Ashpole <[email protected]>
This is a proposal to address Resource and Entity data model interactions, including a path forward to address immediate friction and issues in the current resource specification. The proposal includes all links and context needed to justify it, but duplicating a snapshot here: ## Motivation This proposal attempts to focus on the following problems within OpenTelemetry to unblock multiple working groups: - Allowing mutating attributes to participate in Resource ([OTEP 208](open-telemetry#208)). - Allow Resource to handle entities whose lifetimes don't match the SDK's lifetime ([OTEP 208](open-telemetry#208)). - Provide support for async resource lookup ([spec#952](open-telemetry/opentelemetry-specification#952)). - Fix current Resource merge rules in the specification, which most implementations violate ([oteps#208](open-telemetry#208), [spec#3382](open-telemetry/opentelemetry-specification#3382), [spec#3710](open-telemetry/opentelemetry-specification#3710)). - Allow semantic convention resource modeling to progress ([spec#605](open-telemetry/opentelemetry-specification#605), [spec#559](open-telemetry/opentelemetry-specification#559), etc). --------- Co-authored-by: Tigran Najaryan <[email protected]> Co-authored-by: jack-berg <[email protected]> Co-authored-by: Arve Knudsen <[email protected]> Co-authored-by: David Ashpole <[email protected]>
This is a proposal to address Resource and Entity data model interactions, including a path forward to address immediate friction and issues in the current resource specification. The proposal includes all links and context needed to justify it, but duplicating a snapshot here: ## Motivation This proposal attempts to focus on the following problems within OpenTelemetry to unblock multiple working groups: - Allowing mutating attributes to participate in Resource ([OTEP 208](open-telemetry#208)). - Allow Resource to handle entities whose lifetimes don't match the SDK's lifetime ([OTEP 208](open-telemetry#208)). - Provide support for async resource lookup ([spec#952](open-telemetry/opentelemetry-specification#952)). - Fix current Resource merge rules in the specification, which most implementations violate ([oteps#208](open-telemetry#208), [spec#3382](open-telemetry/opentelemetry-specification#3382), [spec#3710](open-telemetry/opentelemetry-specification#3710)). - Allow semantic convention resource modeling to progress ([spec#605](open-telemetry/opentelemetry-specification#605), [spec#559](open-telemetry/opentelemetry-specification#559), etc). --------- Co-authored-by: Tigran Najaryan <[email protected]> Co-authored-by: jack-berg <[email protected]> Co-authored-by: Arve Knudsen <[email protected]> Co-authored-by: David Ashpole <[email protected]>
This is a proposal to address Resource and Entity data model interactions, including a path forward to address immediate friction and issues in the current resource specification. The proposal includes all links and context needed to justify it, but duplicating a snapshot here: ## Motivation This proposal attempts to focus on the following problems within OpenTelemetry to unblock multiple working groups: - Allowing mutating attributes to participate in Resource ([OTEP 208](open-telemetry/oteps#208)). - Allow Resource to handle entities whose lifetimes don't match the SDK's lifetime ([OTEP 208](open-telemetry/oteps#208)). - Provide support for async resource lookup ([spec#952](open-telemetry#952)). - Fix current Resource merge rules in the specification, which most implementations violate ([oteps#208](open-telemetry/oteps#208), [spec#3382](open-telemetry#3382), [spec#3710](open-telemetry#3710)). - Allow semantic convention resource modeling to progress ([spec#605](open-telemetry#605), [spec#559](open-telemetry#559), etc). --------- Co-authored-by: Tigran Najaryan <[email protected]> Co-authored-by: jack-berg <[email protected]> Co-authored-by: Arve Knudsen <[email protected]> Co-authored-by: David Ashpole <[email protected]>
This is a proposal to address Resource and Entity data model interactions, including a path forward to address immediate friction and issues in the current resource specification. The proposal includes all links and context needed to justify it, but duplicating a snapshot here: ## Motivation This proposal attempts to focus on the following problems within OpenTelemetry to unblock multiple working groups: - Allowing mutating attributes to participate in Resource ([OTEP 208](open-telemetry#208)). - Allow Resource to handle entities whose lifetimes don't match the SDK's lifetime ([OTEP 208](open-telemetry#208)). - Provide support for async resource lookup ([spec#952](open-telemetry/opentelemetry-specification#952)). - Fix current Resource merge rules in the specification, which most implementations violate ([oteps#208](open-telemetry#208), [spec#3382](open-telemetry/opentelemetry-specification#3382), [spec#3710](open-telemetry/opentelemetry-specification#3710)). - Allow semantic convention resource modeling to progress ([spec#605](open-telemetry/opentelemetry-specification#605), [spec#559](open-telemetry/opentelemetry-specification#559), etc). --------- Co-authored-by: Tigran Najaryan <[email protected]> Co-authored-by: jack-berg <[email protected]> Co-authored-by: Arve Knudsen <[email protected]> Co-authored-by: David Ashpole <[email protected]>
This is a proposal to address Resource and Entity data model interactions, including a path forward to address immediate friction and issues in the current resource specification. The proposal includes all links and context needed to justify it, but duplicating a snapshot here: ## Motivation This proposal attempts to focus on the following problems within OpenTelemetry to unblock multiple working groups: - Allowing mutating attributes to participate in Resource ([OTEP 208](open-telemetry#208)). - Allow Resource to handle entities whose lifetimes don't match the SDK's lifetime ([OTEP 208](open-telemetry#208)). - Provide support for async resource lookup ([spec#952](open-telemetry/opentelemetry-specification#952)). - Fix current Resource merge rules in the specification, which most implementations violate ([oteps#208](open-telemetry#208), [spec#3382](open-telemetry/opentelemetry-specification#3382), [spec#3710](open-telemetry/opentelemetry-specification#3710)). - Allow semantic convention resource modeling to progress ([spec#605](open-telemetry/opentelemetry-specification#605), [spec#559](open-telemetry/opentelemetry-specification#559), etc). --------- Co-authored-by: Tigran Najaryan <[email protected]> Co-authored-by: jack-berg <[email protected]> Co-authored-by: Arve Knudsen <[email protected]> Co-authored-by: David Ashpole <[email protected]>
This is a proposal to address Resource and Entity data model interactions, including a path forward to address immediate friction and issues in the current resource specification. The proposal includes all links and context needed to justify it, but duplicating a snapshot here: ## Motivation This proposal attempts to focus on the following problems within OpenTelemetry to unblock multiple working groups: - Allowing mutating attributes to participate in Resource ([OTEP 208](open-telemetry/oteps#208)). - Allow Resource to handle entities whose lifetimes don't match the SDK's lifetime ([OTEP 208](open-telemetry/oteps#208)). - Provide support for async resource lookup ([spec#952](#952)). - Fix current Resource merge rules in the specification, which most implementations violate ([oteps#208](open-telemetry/oteps#208), [spec#3382](#3382), [spec#3710](#3710)). - Allow semantic convention resource modeling to progress ([spec#605](#605), [spec#559](#559), etc). --------- Co-authored-by: Tigran Najaryan <[email protected]> Co-authored-by: jack-berg <[email protected]> Co-authored-by: Arve Knudsen <[email protected]> Co-authored-by: David Ashpole <[email protected]>
The Merge section of the Resource SDK specification, describes how the
schemaURL
of two resources should be merged. But it is unclear what should happen if one of the merging resources is empty, meaning, has 0 attributes but a non-empty schema url.For ex, given this scenario:
https://opentelemetry.io/docs/specs/otel/schemas/v1.2.0
According with the merge behavior, the resulting resource should receive the schema url of the updating resource.
I wonder if this is correct? Given the resource that will influence the ultimate schema has no attributes, would it be better if, in that case, no schema would be set? Or should the schema be set regardless?
The text was updated successfully, but these errors were encountered: