Nick Knize

> I thought the knn plugin API applies to both lucene and native engine but they are only for native engines. ++ sounds good. So then I propose a `vector`...

If there's no opposition then I'll move this issue to core because it'll essentially be a no-op for kNN. kNN can decide in the future whether to simplify the vector...

> Not sure we can keep the same API format after moving the lucene engine into core. Sure you can. FieldMappers implementations are independent of the underlying `context.doc().add()` wrapped lucene...

As a reference, this is similar to how I supported QuadTree, GeoHashPrefixTree, and BKD implementations of `geo_point` and `geo_shape` field mappers and extended them in Elastic XPack to support cartesian...

> What is the motivation to move the vector field as a first class citizen in Opensearch core repo? There are users of OpenSearch min distribution that need vector types...

I agree 💯

> **Do we actually see backward compatibility issue?** > I think NO. Since core is a min distribution, moving something to core should not break customer experience. For the most...

> Is anyone making any updates to this (@nknize )? We are targeting next week to publish it. Thanks! Yes. I'll put the example in tomorrow.

> Otherwise, we'll need to hold this until next Wednesday. Let's hold to Wednesday. I was working up the example with the published artifacts and noticed they don't support Spark...

@pajuric The blocker right now is that the released OpenSearched-Hadoop artifacts are [not compatible with Spark 3](https://central.sonatype.com/artifact/org.opensearch.client/opensearch-hadoop/1.0.1/dependencies). Thus the compatibility matrix in this blog post is not correct and the...