I have started to work on the RFC, that was merged yesterday https://github.com/elastic/ecs/pull/2598/changes - it has introduced new entity fields under existing leaves, that were previously defined as just object
The problem lays in defining leaves for entity.relationships.depends_on.* and similar objects. In the text we do define that Value must be an object whose keys are those defined in Allowed keys on entity.relationships.* objects. That is predefined array: entity.id, host.id, host.name, user.id, user.name, user.email, user.domain, service.id, service.name. Each key holds a keyword array of identifiers.
In RFC we don’t define it precisely, it’s just in the description. This results in generated artifacts with simple object type for each leaf node. So despite we do have a predefined structure we don’t enforce it.
And we have 2 options:
Define every set explicit under each leaf fields. That would be repetition of 9 fields * 4 relationships = 36 entry fields.
It’s verbose, works as is without redefining anything, so generated files will be correct
Pros: easy to implement
Cons: too verbose, one need to make changes in 4 places if updating/adding new fields to the sub-object.
Define a new fieldset, that consists of these 9 fields and re-use it under every leaf node in entity.relationships
Pros: defined once and then reusable
Cons: is this fieldset generic enough to be a new “namespace” within ECS on the top level?
@uri-weisman @taylor-swanson @andrewkroh
I have started to work on the RFC, that was merged yesterday https://github.com/elastic/ecs/pull/2598/changes - it has introduced new entity fields under existing leaves, that were previously defined as just
objectThe problem lays in defining leaves for
entity.relationships.depends_on.*and similar objects. In the text we do define thatValue must be an object whose keys are those defined in Allowed keys onentity.relationships.*objects. That is predefined array:entity.id,host.id,host.name,user.id,user.name,user.email,user.domain,service.id,service.name. Each key holds a keyword array of identifiers.In RFC we don’t define it precisely, it’s just in the description. This results in generated artifacts with simple
objecttype for each leaf node. So despite we do have a predefined structure we don’t enforce it.And we have 2 options:
Define every set explicit under each leaf fields. That would be repetition of 9 fields * 4 relationships = 36 entry fields.
It’s verbose, works as is without redefining anything, so generated files will be correct
Pros: easy to implement
Cons: too verbose, one need to make changes in 4 places if updating/adding new fields to the sub-object.
Define a new fieldset, that consists of these 9 fields and re-use it under every leaf node in
entity.relationshipsPros: defined once and then reusable
Cons: is this fieldset generic enough to be a new “namespace” within ECS on the top level?
@uri-weisman @taylor-swanson @andrewkroh