Define an Entity Merge algorithm (from OTEP #264)#4768
Define an Entity Merge algorithm (from OTEP #264)#4768jsuereth wants to merge 14 commits intoopen-telemetry:mainfrom
Conversation
jsuereth
added
spec:resource
| resource. | ||
|
|
||
| - Construct a set of existing entities on the resource, `E`. | ||
| - For each entity, `new_entity`, in priority order (highest first), |
There was a problem hiding this comment.
How does an SDK determine the relative priority of entities?
There was a problem hiding this comment.
resource detection configuration
specification/resource/data-model.md
Outdated
| - For each entity, `new_entity`, in priority order (highest first), | ||
| do one of the following: | ||
| - If an entity `e'` exsits in `E` with the same entity type as `new_entity`: | ||
| - Perform a [Entity DataModel Merge](../entities/data-model.md#merging-of-entities), if applicable, otherwise ignore `new_entity`. |
There was a problem hiding this comment.
if applicable
nit: maybe rephrase to "if they are mergeable"? If applicable confused me here.
otherwise ignore
new_entity.
Do we consider this an error (e.g. surfaced using the SDK error handler or logged as a warning in the collector)? This makes it sound like these cases should be silently ignored.
There was a problem hiding this comment.
Yes it is considered to be an error case (or at least a misconfiguration). I think the term "ignore" just relates to what the SDK should construct in order to emit telemetry. Logging an error is also acceptable
jsuereth
force-pushed
the
wip-entity-merge
branch
from
3374dd3 to
de9dd47
Compare
|
This PR was marked stale. It will be closed in 14 days without additional activity. |
jsuereth
moved this from Phase 1: Resource <-> Entity Mapping
to In Progress
in Entities: Phase 1
| ## Merging of Entities | ||
|
|
||
| Entities MAY be merged if and only if their types are the same, their | ||
| identity attributes are exactly the same AND their schema_url is the same. |
There was a problem hiding this comment.
Do you see a possibility to relax the last requirement a bit? For example can we aim for: "schema_url is the same or schemas are compatible", where "schemas are compatible" if attributes used by Entities are unchanged between schema versions? I understand it is more work to check compatibility but it makes merging much more widely possible.
There was a problem hiding this comment.
So in that event, we expect the following:
- The SDK/Collector has no way of knowing if a schema_url is compatible with another, without looking at the schema.
- If we have to look at the schema, we can convert the version succesffuly, and then we can merge two entities that are at the same version.
So while we do want to allow schema_url based conversions, the merge algorithm for Entities can be defined much more simply and we leave room for version-conversion prior to this.
|
|
||
| ### Merging Entities into a Resource | ||
|
|
||
| We define the following algorithm for merging entities into an existing |
There was a problem hiding this comment.
This is a fairly complicated algorithm. Can you please add a few examples to demonstrate what it is doing?
Co-authored-by: Dmitry Anoshin <anoshindx@gmail.com>
6 participants
Changes
Adds the merge algorithm specified in OTEP#264 to the Resource + Entity data model specification (both still in development).
This merge algorithm has been used in Entity prototypes for the past year and has not seen any change. It's been adaptable enough to handle several re-architectures of SDKs through prototyping, so we're confident in pushing it forward into the specification.
A few caveats:
Link to prototypes: