Add Entity Type Uniqueness and Attribute Ownership restrictions #4697
Conversation
While working on adding API for managing the Resource Entity references in collector pipelines, I found that it's very complicated to maintain data integrity if we don't explicitly impose the following restrictions on the data model: 1. Entity Type Uniqueness: Enforces that all entities within a resource must have unique types, ensuring unambiguous identification and preventing attribute key collisions when combined with the prefix naming convention. 2. Attribute Ownership: Ensures each resource attribute key is owned by at most one entity, preventing data inconsistencies from multiple entities competing for control of the same attribute.
dmitryax force-pushed the add-entity-resource-integrity-restrictions branch from 17a3002 to faead7f Compare 
| The uniqueness requirement at least I think is implied by the merge rules https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/entities/0264-resource-and-entities.md#entity-merging-and-resource I had thought the attribute ownership requirement was also in the OTEP but I can't find it. In any case, I think this is overall a good idea to clarify and should be in the spec anyway not just oteps. This is a draft so I'll hold off on review but +1 on the idea. |
jsuereth left a comment
jsuereth left a comment There was a problem hiding this comment.
Overall supportive of this. I think we need this definition here.
I do think we need to account for failure scenarios, so holding of an approval until we either add that section or mark a TODO to add that section.
| otherwise compete for control of the same attribute. | ||
| | ||
| For identifying attributes, ownership is implicitly enforced by the combination | ||
| of entity type uniqueness and the prefix naming convention. For descriptive |
There was a problem hiding this comment.
I'm skeptical of relying on naming conventions here. I think we likely need something to describe what to do if folks fail to use our naming conventions going forward (it will happen, so we should make sure we don't get invalid Resources when it does, if we can help it.
In light of how other SDK/model behavior is - we should call out that this would be an error scenario in the model - and we'll be recommending SDKs have some kind of "error log + fallback" behavior.
There was a problem hiding this comment.
Good point. I've added an Implementation Note to address validation and fallback strategies with given data model restrictions. Since this document isn't intended to provide SDK guidance as far as I understand, I kept it as a note rather than normative requirements.
On the naming convention strictness - the current semantic conventions already follow this pattern (host.id, k8s.node.uid, etc.). I'd prefer keeping the stricter requirement until we encounter concrete cases that break it during semantic convention development.
| This PR was marked stale due to lack of activity. It will be closed in 7 days. |
| Closed as inactive. Feel free to reopen if this PR is still being worked on. |
3 participants
While working on adding API for managing the Resource Entity references in collector pipelines, I found that it's very complicated to maintain data integrity if we don't explicitly impose the following restrictions on the data model:
Entity Type Uniqueness: Enforces that all entities within a resource must have unique types, ensuring unambiguous identification and preventing ID attribute key collisions when combined with the prefix naming convention.
Attribute Ownership: Ensures each resource attribute key is owned by at most one entity, preventing description attribute key collisions and data inconsistencies from multiple entities competing for control of the same attribute.
CHANGELOG.mdfile updated for non-trivial changes