Andrew Ross

@bbarani Yes, we can. If the goal is that all repositories just have a common base set of labels, then we can define them in a base repository and build...

@jainankitk I'm fine with taking this change in 3.0.

@dzane17 @jainankitk This will break [k-NN](https://github.com/opensearch-project/k-NN/blob/main/src/main/java/org/opensearch/knn/plugin/KNNPlugin.java#L364-L375). We should update ensure k-NN gets updated before merging this change (either open an issue with a specific suggestion or create a PR directly).

Asynchronous search seems like a low-level building block that other features and plugins would build on top of, and as such seems like a good candidate to build directly into...

> The idea is to bake this into core, so that existing search users/other search plugins(SQL/PPL/kNN) are able to leverage the same and also to unify search experience by having...

> Could we just move the code from this repo to OpenSearch core's `/plugins/` directory? @msfroh That goes against what we've recently recommended for other plugins. We'd need to be...

I'll also note that 7 of the 19 open issues in this repo right now now are related to failing and/or flaky tests. That does not make me enthusiastic about...

If the data in `.opendistro-job-scheduler-lock` is truly ephemeral state that should _never_ survive a snapshot->restore cycle, then it might be appropriate to block it from being snapshotted. However, it does...

> We can also have user to first rename the index to a new name during restoration, delete the original index, and then reindex the data from the renamed index...

I almost closed this due to age, but the flaky tests in question here are marked as ignored so this is still very much a problem: https://github.com/dblock/job-scheduler/blob/main/spi/src/test/java/org/opensearch/jobscheduler/spi/utils/LockServiceIT.java#L280 https://github.com/dblock/job-scheduler/blob/main/spi/src/test/java/org/opensearch/jobscheduler/spi/utils/LockServiceIT.java#L355