Michael Froh

> @msfroh it looks pretty clever and clean! Besides docs, could you please add tests to `rest-api-specs` ? Sure thing! I'm flying to Berlin today, but I'll try to write...

Added rest-api-spec tests: https://github.com/opensearch-project/OpenSearch/pull/13461/commits/3ee80ee9d7c50541b4fc34ce667c9e14edd0b5ac And created a documentation PR: https://github.com/opensearch-project/documentation-website/pull/7339

> Plugins should be able to define other persistent storage alternatives than the cluster state or system indices. Options include remote clusters, non-relational databases (MongoDB, NoSQL, DynamoDB, Apache Cassandra, HBase,...

@andrross -- Yes! That's exactly the approach that I was thinking of -- pluggable metadata storage, where the producers/consumers don't care *how* it works or *where* the metadata is stored,...

> @msfroh @ansjcy - I have similar concerns around security/validation as @sohami regarding Approach 1. Do we need to augment our existing security model to prevent identity spoofing? My thinking...

Why did you implement this as a new API, rather than adding it to the existing `NodeInfo`? I'm not necessarily suggesting that it's better to add it to `NodeInfo`, but...

> also we could make it opt-in ( by adding a new analyzers metric, GET /_nodes/analyzers, [1]) so it will be only returned on demand It looks like `NodesInfoRequest` defaults...

> @msfroh Just FYI I am introducing a "default" set of metrics to NodesInfoRequest. Compared to all set it will not include analyzers AND search_pipelines. So by default these two...

@jmazanec15 do you need to include the field in the source? You could exclude it from the source with ```json "mapping": { "_source": { "excludes": [ "knn_vector_field" // Or whatever...

@hasnain2808, you expressed some interest in working on this, right?