Add the cluster version to enrich policies when they are created. #44595
Conversation
jbaiera
added
>non-issue
:Data Management/Ingest Node
|
Pinging @elastic/es-core-features |
| parser.declareString(ConstructingObjectParser.constructorArg(), ENRICH_KEY); | ||
| parser.declareStringArray(ConstructingObjectParser.constructorArg(), ENRICH_VALUES); | ||
| PARSER.declareString(ConstructingObjectParser.constructorArg(), NAME); | ||
| PARSER.declareField(ConstructingObjectParser.constructorArg(), (p, c) -> Version.fromString(p.text()), VERSION_CREATED, |
There was a problem hiding this comment.
Can newer ES versions create a Version object (via the fromString) that is not explicitly defined. e.g. what happens if version 6.8.0 is the version serialized can this read it ?
There was a problem hiding this comment.
Yes - The fromString() method condenses the version string given down into the integral version id. If the version id isn't defined in the known list of versions, it is still created, but the version of lucene that it associates with the returned version is a guess. I don't foresee this being an issue, but I could be off base here.
|
|
||
| public Response(Map<String, EnrichPolicy> policies) { | ||
| Objects.requireNonNull(policies, "policies cannot be null"); | ||
| // use a treemap to guarantee ordering in the set, then transform it to the list of named policies |
There was a problem hiding this comment.
nit: remove the comment, this no longer uses a Treemap
| builder.field(NAME.getPreferredName(), name); | ||
| builder.field(VERSION_CREATED.getPreferredName()); | ||
| versionCreated.toXContent(builder, params); | ||
| builder.startObject(DEFINITION.getPreferredName()); |
There was a problem hiding this comment.
does the definition need be a sub object ?
| - match: { enrich_key: baz } | ||
| - match: { enrich_values: ["a", "b"] } | ||
| - match: { name: policy-crud } | ||
| - match: { definition.type: exact_match } |
There was a problem hiding this comment.
asked above ^^ if can avoid the definition sub object .
|
Is it possible to keep this as single policy object which can optionally serialize/deserialize the extra two fields ? |
I wanted to avoid having fields on the policy object that would need to be handled specially for the purposes of serialization. More specifically, a user shouldn't be able to set the |
|
Maybe introduce a second map in |
|
Closing this out in favor of #45021 - It accomplishes the same thing, but with less ripple effect. |
4 participants
This PR adds version information to an EnrichPolicy when it is created to aid with backwards compatibility logic. The old EnrichPolicy object has been renamed to
EnrichPolicyDefinitionand a newEnrichPolicyobject has been created, one that holds the version of Elasticsearch that the policy was created on. I also added the name to the policy object since in many places we are passing the name around along with the policy definition. All response objects have been updated to return the new policy structure. Now when a get operation is performed, the following is returned:{ "name": "policy-name", "version_created": "8.0.0", "definition": { "type": "exact_match", "indices": ["source_index"], "query": { ... }, "enrich_key": "keyname", "enrich_values": ["field1", "field2", "field3"] } }