Resource conventions: Compute Instance vs Compute Unit unclear #559
Labels
area:semantic-conventions
Related to semantic conventions
release:after-ga
Not required before GA release, and not going to work on before GA
spec:resource
Related to the specification/resource directory
Milestone
Comments
arminru
added
area:semantic-conventions
reyang
added
the
release:required-for-ga
andrewhsu
added
priority:p3
|
from the spec sig mtg today, discussed this issue and bumped priority to p3 for the required-for-ga release |
|
Relatedly the TOC hierarchy for "Deployment" is a bit odd: #851 (comment) |
Oberon00
added
release:after-ga
|
This is just an editorial change (changing section headers or merging/splitting section), I think this is after GA. |
tigrannajaryan
added a commit
to open-telemetry/oteps
that referenced
this issue
Sep 26, 2024
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]>
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this issue
Oct 21, 2024
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]>
carlosalberto
pushed a commit
to carlosalberto/oteps
that referenced
this issue
Oct 23, 2024
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]>
carlosalberto
pushed a commit
to carlosalberto/oteps
that referenced
this issue
Oct 23, 2024
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]>
carlosalberto
pushed a commit
to carlosalberto/oteps
that referenced
this issue
Oct 30, 2024
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]>
carlosalberto
pushed a commit
to carlosalberto/opentelemetry-specification
that referenced
this issue
Oct 31, 2024
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]>
carlosalberto
pushed a commit
to carlosalberto/oteps
that referenced
this issue
Oct 31, 2024
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]>
carlosalberto
pushed a commit
to carlosalberto/oteps
that referenced
this issue
Nov 1, 2024
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]>
carlosalberto
pushed a commit
that referenced
this issue
Nov 8, 2024
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]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See https://github.com/open-telemetry/opentelemetry-specification/tree/c04041e16c9571b7ee5cfd5f102fc15e94ffacd7/specification/resource/semantic_conventions#compute-unit and https://github.com/open-telemetry/opentelemetry-specification/tree/c04041e16c9571b7ee5cfd5f102fc15e94ffacd7/specification/resource/semantic_conventions#compute-instance
Compute Unit currently only has Host as an entry.
On the other hand a Serverless Function (FaaS) is currently a Compute Unit but has attributes like
faas.instance, suggesting that it might be an instance. Also containers are the runtime incarnations/instances of images. Probably we should just merge these sections.To bring in even more confusion, under "Deployment Services" (https://github.com/open-telemetry/opentelemetry-specification/tree/c04041e16c9571b7ee5cfd5f102fc15e94ffacd7/specification/resource/semantic_conventions#deployment-service) we find k8s.pod.name and according to https://kubernetes.io/docs/concepts/workloads/pods/pod/ "A Pod (as in a pod of whales or pea pod) is a group of one or more containers" so if a container is an instance, so is a POD.
The text was updated successfully, but these errors were encountered: