[MD] onboard TSVB to support multiple data source

[zhongnansu]

Signed-off-by: Su szhongna@amazon.com

Description

[require UX/UI changes to go along]

[MD] onboard TSVB to support multiple data source
Unlike other vis types, TSVB has its own backend. From the expressions TSVB generated, it doesn't go through opensearchaggs to create the searchSource obj, and call high level search API. Instead, they retrieve the index pattern, build the OpenSearch query from their plugin and directly query OpenSearch in 2 ways.

1. by calling the data plugin low level search API, to get actual data
2. directly use legacyOpenSearchClient to query OS to get runtime fields and fields capabilities.

This PR targets to refactor above 2 flows by integrating with datasource params. That also requires adding MD as an optional plugin of TSVB

See issue below for more details

Issues Resolved

#2153
part of #1990

Check List

• All tests pass
  • yarn test:jest
  • yarn test:jest_integration
  • yarn test:ftr
• New functionality includes testing.
• New functionality has been documented.
• Update CHANGELOG.md
• Commits are signed per the DCO using --signoff

[ashwin-pc]

@zhongnansu A High level question about the abstraction here. Since multi datasource is tightly coupled with the data plugin, wouldnt it make sense to have the data plugin directly responsible for determining the datasource given the existing data? Or am i missing something about why this is not possible?

My naive thinking is that the datasource integration happens at the lowest level of the data plugin where it knows which datasource is related to any given index pattern. So other plugins (including TSVB) can operate under the assumption that there are only index patterns without worrying about what the underlying datasource is.

[zhongnansu]

@zhongnansu A High level question about the abstraction here. Since multi datasource is tightly coupled with the data plugin, wouldnt it make sense to have the data plugin directly responsible for determining the datasource given the existing data? Or am i missing something about why this is not possible?

@ashwin-pc
Most logic of data source is still in data source plugin. Data plugin optionally depends on data source plugin. Yes and there's actually logic in data plugin to decide datasource based on the input index pattern. It's within data plugin high level search API SearchSource. Most of the vis plugins go through that API by generating opensearchagg field in the expression. So no need to make any changes in those visualizations, it will adapt to data source use case. For TSVB, that's not the case.

Like I mentioned in the PR description. TSVB is different with other vis in the way it queries data.

1. query fields meta data: it doesn't even go through data plugin to query data, instead, TSVB directly uses legacy client to talk to OS. For this case, we can't even push down the logic to data plugin.
2. query actual data: it goes though low level data plugin search API, where we need dataSourceId as param. For this part we can consider how to push down the logic of deciding client to low level API. It requires bigger refactor of data plugin. Because low level api doesn't get much info of index-pattern, only the name. Compare to high level API, where we already have the index pattern object there. I'd love to add it to the enhancement, and needs more research. [MD]Client management further optimization #2006

[ashwin-pc]

@zhongnansu Thanks for the context! I didn't know the difference between the low and high level data plugin api's. I know the answer to my question is probably no, but did you look to see if you could change TSVB to use the high level api instead? If you have, just ignore my comment 😄

Also, not for this PR, but given all the recent investigations and work that has gone into the data plugin and how it works, can we also update its readme? For what it does, its quite limited in its documentation. https://github.com/opensearch-project/OpenSearch-Dashboards/blob/main/src/plugins/data/README.md.
cc: @kristenTian @seraphjiang

[seraphjiang]

Thanks @ashwin-pc and @zhongnansu for great discussion.

Good suggestion to keep the update to date

[ashwin-pc]

@zhongnansu is this still in the works or can we close it?

[zhongnansu]

@zhongnansu is this still in the works or can we close it?

Closing the PR for now. There are some blockers and prioritization change to this task. @ashwin-pc