From a7cceb97f90d15f12a8229090209cac3be4395c2 Mon Sep 17 00:00:00 2001 From: Su Date: Tue, 11 Oct 2022 10:48:55 -0700 Subject: [PATCH] update wording Signed-off-by: Su --- .../docs/client_management_design.md | 18 ++--- .../data_source/docs/high_level_design.md | 70 +++++++++---------- src/plugins/data_source/docs/user_stories.md | 24 +++---- 3 files changed, 56 insertions(+), 56 deletions(-) diff --git a/src/plugins/data_source/docs/client_management_design.md b/src/plugins/data_source/docs/client_management_design.md index d97c36f4156e..de89699d10c9 100644 --- a/src/plugins/data_source/docs/client_management_design.md +++ b/src/plugins/data_source/docs/client_management_design.md @@ -1,8 +1,8 @@ -# [OSD Multi Data Source] Client Management +# [OpenSearch Dashboards Multi Data Source] Client Management ## 1. Problem Statement -This design is part of the OSD multi data source project [[RFC](https://github.com/opensearch-project/OpenSearch-Dashboards/issues/1388)], where we need to manage and expose clients. Connections are established through creating OpenSearch clients. Then clients can be used by caller to interact with any data source(OpenSearch is the only data source type in scope at this phase). +This design is part of the OpenSearch Dashboards multi data source project [[RFC](https://github.com/opensearch-project/OpenSearch-Dashboards/issues/1388)], where we need to manage and expose clients. Connections are established through creating OpenSearch clients. Then clients can be used by caller to interact with any data source(OpenSearch is the only data source type in scope at this phase). **Overall the critical problems we are solving are:** @@ -14,7 +14,7 @@ This design is part of the OSD multi data source project [[RFC](https://github.c ## 2. Requirements 1. **Accessibility**: - 1. Clients need to be accessible by other OSD plugins or modules through interfaces, in all stages of the plugin lifecycle. E.g “Setup”, and “Start” + 1. Clients need to be accessible by other OpenSearch Dashboards plugins or modules through interfaces, in all stages of the plugin lifecycle. E.g “Setup”, and “Start” 2. Clients should be accessible by plugin through request handler context. 2. **Client Management**: Clients needs to be reused in a resource-efficient way to not harm the performance (P1) 3. **Backwards compatibility**: if user enables this feature and later disabled it. Any related logic should be able to take in this config change, and deal with any user cases. @@ -40,7 +40,7 @@ This design is part of the OSD multi data source project [[RFC](https://github.c ### 4.0 Answer some critical design questions **1.** **How to set up connection(clients) for different datasources?** -Similar to how current OSD talks to default OS by creating opensearch node.js client using [opensearch-js](https://github.com/opensearch-project/opensearch-js) library, for datasources we also create clients for each. Critical params that differentiate data sources are `url` and `auth` +Similar to how current OpenSearch Dashboards talks to default OS by creating opensearch node.js client using [opensearch-js](https://github.com/opensearch-project/opensearch-js) library, for datasources we also create clients for each. Critical params that differentiate data sources are `url` and `auth` ```ts const { Client } = require(['@opensearch-project/opensearch'](https://github.com/opensearch-project/opensearch-js)); @@ -70,7 +70,7 @@ const dataSourceClient: OpenSearchClient = core.openearchData.client ``` **3.How to maintain backwards compatibility if user turn off this feature?** -Context is user can only turn off this feature by updating `osd.yml` and reboot. Configs are accessible from `ConfigService` in core. +Context is user can only turn off this feature by updating `opensearch_dashboards.yml` and reboot. Configs are accessible from `ConfigService` in core. 1. **Browser side**, is datasource feature is turned off, browser should detect the config change and update UI not allowing request to submit to datasource. If the request is not submitted to a datasource, the logic won’t return a datasource client at all. 2. **Server side**, if user submits the request to datasource manually, on purpose. Or the plugin tries to access datasource client from server side. In the corresponding core service we’ll have a **flag** that maps to the **enable_multi_datasource** boolean config, and throw error if API is called while this feature is turned off. @@ -110,7 +110,7 @@ Currently [`core-opensearch`](https://github.com/opensearch-project/OpenSearch-D - **opensearch_service**: hold a `ClusterClient` instance - **[client module](https://github.com/opensearch-project/OpenSearch-Dashboards/tree/d7004dc5b0392477fdd54ac66b29d231975a173b/src/core/server/opensearch/client)**: the utilities and interfaces for creating `ClusterClient` - - internalClient: read only. (create as OSD internal user, system user) + - internalClient: read only. (create as OpenSearch Dashboards internal user, system user) - ScopedClient: read only. (as current user) - asScoped(): function that create child clients of the read only ScopeClient for current user @@ -140,7 +140,7 @@ export interface IDataSourceClient { - extends `IDataSourceClient` - Add local variable **isDataSourceEnabled** - - The value of flag is mapped to the boolean configuration “enable_multi_datasource” in osd.yml. Flag to determine if feature is enabled. If turned off, any access to dataSourceClient will be rejected and throw error + - The value of flag is mapped to the boolean configuration “enable_multi_datasource” in `opensearch_dashboards.yml`. Flag to determine if feature is enabled. If turned off, any access to dataSourceClient will be rejected and throw error - Add local variable **rootDataSourceClientCollection** - Map (initialize as empty or take user config to add Clients) - Implement the new function `asDataSource` as shown in above `IDataSourceClient` interface. Params and return type is clear @@ -148,10 +148,10 @@ export interface IDataSourceClient { - **Functionality** - Throw error if **isDataSourceEnabled == false** - Look up Client Pool by datasource id, return client if existed - - Use `Saved_Object` Client to retrieve datas source info from OSD system index and parse to `DataSource` object + - Use `Saved_Object` Client to retrieve datas source info from OpenSearch Dashboards system index and parse to `DataSource` object - Call credential manager utilities to **decrypt** user credentials from `DataSource` Object - Create Client using dataSource metadata, and decrypted user credential - - \*Optimization: If same endpoint but different user credential, we’ll leverage the openearch-js connection pooling strategy to create client by `.child()` + - Optimization: If same endpoint but different user credential, we’ll leverage the openearch-js connection pooling strategy to create client by `.child()` ### 4.3 Register datasource client to core context diff --git a/src/plugins/data_source/docs/high_level_design.md b/src/plugins/data_source/docs/high_level_design.md index da8152f3019e..e3a420fc5e28 100644 --- a/src/plugins/data_source/docs/high_level_design.md +++ b/src/plugins/data_source/docs/high_level_design.md @@ -1,4 +1,4 @@ -# OSD Multiple Data Source Support HLD +# OpenSearch Dashboards Multiple Data Source Support HLD OpenSearch Dashboards is designed and implemented to only work with one single OpenSearch cluster. This documents discusses the design to enable OpenSearch Dashboards to work with multiple OpenSearch endpoints, which can be a centralized data visualization and analytics application. @@ -8,14 +8,14 @@ For more context, see RFC [Enable OpenSearch Dashboards to support multiple Open [OpenSearch Dashboards Multiple OpenSearch Data Source Support User Stories](user_stories.md) -From very high level, we propose to introduce `data-source` as a new OSD saved object type. +From very high level, we propose to introduce `data-source` as a new OpenSearch Dashboards saved object type. ## Terminologies -- **Dashboards metadata**: refers to data documents saved in the opensearch_dashboards index. Equivalent to Dashboards **saved objects**. +- **Dashboards metadata**: refers to data documents saved in the `.opensearch_dashboards` index. Equivalent to Dashboards **saved objects**. - **User data**: in this document, user data refers to the log, metrics or search catalog data that saved in OpenSearch, users run analysis against these user data with OpenSearch Dashboards. -- **Data source**: an Opensearch endpoint, it could be a on-prem cluster, or AWS managed OpenSearch domain or a serverless collection, which stores the user log/metrics data for visualization and analytics purpose. - - in this document, we may also refer data source as a new type of OSD saved objects, which is a data model to describe a data source, including endpoint, auth info, capabilities etc. +- **Data source**: an OpenSearch endpoint, it could be a on-prem cluster, or AWS managed OpenSearch domain or a serverless collection, which stores the user log/metrics data for visualization and analytics purpose. + - in this document, we may also refer data source as a new type of OpenSearch Dashboards saved objects, which is a data model to describe a data source, including endpoint, auth info, capabilities etc. ## Scope @@ -29,7 +29,7 @@ We are targeting to release the multiple data source support in OpenSearch 3.0 p - plugins like AD/Alerting/ISM doesn’t work with data source - DevTool console maybe in scope depending on the progress and resource - Observability visualizations are out of scope -- data source support can be enabled/disable based on config in OSD yml config file +- data source support can be enabled/disable based on config in OpenSearch Dashboards yml config file - multiple data source project doesn’t change existing security experience - e.g. if a user have access to a security tenant, they will be able to use the data sources defined in that tenant @@ -45,14 +45,14 @@ We are targeting to release the multiple data source support in OpenSearch 3.0 p ### Functional requirements -- OSD users should be able to dynamically add/view/update/remove OpenSearch data sources using UI and API -- OSD users should be able to save/update/remove credentials( username/password in preview, and AWS Sigv4 in GA) -- OSD users can create index pattern with specific data source +- OpenSearch Dashboards users should be able to dynamically add/view/update/remove OpenSearch data sources using UI and API +- OpenSearch Dashboards users should be able to save/update/remove credentials( username/password in preview, and AWS Sigv4 in GA) +- OpenSearch Dashboards users can create index pattern with specific data source - Data source credentials should be handled securely -- OSD users can put data visualizations of different data sources into one dashboard +- OpenSearch Dashboards users can put data visualizations of different data sources into one dashboard - OpenSearch analytics and management functions (such as AD, ISM and security) can work with specific data source to manage those functions in corresponding data source - such as user can choose a data source and then edit/view Anomaly detectors and security roles with OpenSearch Dashboards -- OSD should be able to work with self managed and AWS managed +- OpenSearch Dashboards should be able to work with self managed and AWS managed ### Limitations @@ -64,14 +64,14 @@ We are targeting to release the multiple data source support in OpenSearch 3.0 p ### Introducing data source saved object model -Generally, OSD works with 2 kinds of data: +Generally, OpenSearch Dashboards works with 2 kinds of data: 1. User data, such as application logs, metrics, and search catalog data in data indices. -2. OSD metadata, which are the saved objects in `.opensearch_dashboards` index +2. OpenSearch Dashboards metadata, which are the saved objects in `.opensearch_dashboards` index -Currently both OSD metadata and user data indices are saved in the same OpenSearch cluster. However in the case to support OSD to work with multiple OpenSearch data sources, OSD metadata index will be stored in one OpenSearch cluster, and user data indices will be saved in other OpenSearch clusters. Thus we will need to differentiate OSD metadata operations and user data access. +Currently both OpenSearch Dashboards metadata and user data indices are saved in the same OpenSearch cluster. However in the case to support OpenSearch Dashboards to work with multiple OpenSearch data sources, OpenSearch Dashboards metadata index will be stored in one OpenSearch cluster, and user data indices will be saved in other OpenSearch clusters. Thus we will need to differentiate OpenSearch Dashboards metadata operations and user data access. -OSD admin will still define an OpenSearch cluster in the `opensearch.host` config in `opensearch_dashboards.yml` file. It will be used as the OSD metadata store, and OSD metadata will still be saved in the `.opensearch_dashboards index` in this OpenSearch cluster. +OpenSearch Dashboards admin will still define an OpenSearch cluster in the `opensearch.host` config in `opensearch_dashboards.yml` file. It will be used as the OpenSearch Dashboards metadata store, and OpenSearch Dashboards metadata will still be saved in the `.opensearch_dashboards index` in this OpenSearch cluster. Regarding the user data access, we propose to add a new “data-source” saved objects type, which describes a data source connection, such as @@ -79,7 +79,7 @@ Regarding the user data access, we propose to add a new “data-source” saved - auth info, like auth types and credentials to use when accessing the data source - data source capabilities, such as if the data source supports AD/ISM etc. -Users can dynamically add data source in OSD using UI or API, OSD will save the data source saved objects in its metadata index. And then users can do their with with their data sources. For example, when OSD needs to access user data on behalf of the customer, customer will need to specify a data source id, then OSD can fetch the data source info from its metadata store, then send the request to the corresponding data source endpoint. +Users can dynamically add data source in OpenSearch Dashboards using UI or API, OpenSearch Dashboards will save the data source saved objects in its metadata index. And then users can do their with with their data sources. For example, when OpenSearch Dashboards needs to access user data on behalf of the customer, customer will need to specify a data source id, then OpenSearch Dashboards can fetch the data source info from its metadata store, then send the request to the corresponding data source endpoint. So the Dashboards and OpenSearch setup may look like:![img](./img/hld_setup_diagram.png) @@ -87,61 +87,61 @@ Refer to the proposed solution in [#1388](https://github.com/opensearch-project/ ### Data source integration -[opensearch_service](https://github.com/opensearch-project/OpenSearch-Dashboards/tree/main/src/core/server/opensearch) is one of the core modules of OpenSearch Dashboards, it is a singleton instance in OSD which manages OSD connection with the backend OpenSearch endpoint. It makes another level of abstraction of OpenSearch client, and provide a set of interfaces for other OSD modules and plugins to interact with OpenSearch for example running DSL queries, or calling arbitrary OpenSearch APIs. +[opensearch_service](https://github.com/opensearch-project/OpenSearch-Dashboards/tree/main/src/core/server/opensearch) is one of the core modules of OpenSearch Dashboards, it is a singleton instance in OpenSearch Dashboards which manages OpenSearch Dashboards connection with the backend OpenSearch endpoint. It makes another level of abstraction of OpenSearch client, and provide a set of interfaces for other OpenSearch Dashboards modules and plugins to interact with OpenSearch for example running DSL queries, or calling arbitrary OpenSearch APIs. -Currently, OSD only works with one OpenSearch cluster, OSD metadata index and user data indices are stored in the same OpenSearch cluster. So the OSD [saved object service](https://github.com/opensearch-project/OpenSearch-Dashboards/tree/main/src/core/server/saved_objects), which the core OSD module handles all OSD metadata operations, also relies on `opensearch_service` interfaces to work with OpenSearch. +Currently, OpenSearch Dashboards only works with one OpenSearch cluster, OpenSearch Dashboards metadata index and user data indices are stored in the same OpenSearch cluster. So the OpenSearch Dashboards [saved object service](https://github.com/opensearch-project/OpenSearch-Dashboards/tree/main/src/core/server/saved_objects), which the core OpenSearch Dashboards module handles all OpenSearch Dashboards metadata operations, also relies on `opensearch_service` interfaces to work with OpenSearch. -With multi-datasource, we will need to diverge the `opensearch_service` for these 2 use cases. We propose to fork a new `metadata_client` from existing `opensearch_service` to manage the metadata store connection, so that `saved_objects_service` can use `metadata_client` to perform saved objects operations. And then we repurpose the `opensearch_service` to serve the user data access use cases. The new `opensearch_service` needs will expose following interface to allow other OSD components to interact with a specific data source cluster. +With multi-datasource, we will need to diverge the `opensearch_service` for these 2 use cases. We propose to fork a new `metadata_client` from existing `opensearch_service` to manage the metadata store connection, so that `saved_objects_service` can use `metadata_client` to perform saved objects operations. And then we repurpose the `opensearch_service` to serve the user data access use cases. The new `opensearch_service` needs will expose following interface to allow other OpenSearch Dashboards components to interact with a specific data source cluster. ``` core.opensearch.withDataSource().callAsCurrentUser(searchParams) ``` -OSD plugins like data plugin, alerting plugin will need to introduce the data source concept into their use case, letting users to specify a data source when using their functions, and then switch to this new opensearch interface when calling OpenSearch APIs or executing queries. +OpenSearch Dashboards plugins like data plugin, alerting plugin will need to introduce the data source concept into their use case, letting users to specify a data source when using their functions, and then switch to this new opensearch interface when calling OpenSearch APIs or executing queries. ### Multi-datasource support in visualizations -Current OpenSearch Dashboards has 3 major saved object types, index pattern, visualization and Dashboards +Current OpenSearch Dashboards have 3 major saved object types, index pattern, visualization and Dashboards - Visualization works starts with index pattern. An index pattern is a level of data abstraction. Index pattern describes a set of data indices, and their data schema. -- OSD users can create data visualizations against an index pattern. A visualization includes the OpenSearch SDL query, aggregation and a reference to an index pattern, as well as graph metadata such as legend and labels. When rendering a visualization graph, the visualization executes the query& aggregation against that specific index pattern, and draw the graph according to graph settings. -- Then OSD users can place a set of visualizations into a dashboard. A OSD dashboards describes the layout and control (time picker, field filters) of all visualizations on the dashboard. +- OpenSearch Dashboards users can create data visualizations against an index pattern. A visualization includes the OpenSearch SDL query, aggregation and a reference to an index pattern, as well as graph metadata such as legend and labels. When rendering a visualization graph, the visualization executes the query& aggregation against that specific index pattern, and draw the graph according to graph settings. +- Then OpenSearch Dashboards users can place a set of visualizations into a dashboard. A OpenSearch Dashboards dashboards describes the layout and control (time picker, field filters) of all visualizations on the dashboard. -To support multiple data source in OSD, we will add “data source” to index pattern model. One index pattern will have a `dataSourceId` field, so that it refers to a data source. +To support multiple data source in OpenSearch Dashboards, we will add “data source” to index pattern model. One index pattern will have a `dataSourceId` field, so that it refers to a data source. An index pattern can only refer to one data source, one data source can be used by multiple index patterns. -With this new “data source” reference in index pattern, OSD users will need to create data sources in OSD, then select a data source when creating index patterns. Then the visualization and dashboard creation experience will remain the same. +With this new “data source” reference in index pattern, OpenSearch Dashboards users will need to create data sources in OpenSearch Dashboards, then select a data source when creating index patterns. Then the visualization and dashboard creation experience will remain the same. -For OSD multiple data source user experience, refer to [OpenSearch Dashboards Multiple OpenSearch Data Source Support User Stories](https://quip-amazon.com/VXQ0AhpPs3gU) +For OpenSearch Dashboards multiple data source user experience, refer to [OpenSearch Dashboards Multiple OpenSearch Data Source Support User Stories](https://quip-amazon.com/VXQ0AhpPs3gU) -The OSD visualization rendering flow will look like following with multi-datasource support: ![image](./img/hld_vis_flow.png) +The OpenSearch Dashboards visualization rendering flow will look like following with multi-datasource support: ![image](./img/hld_vis_flow.png) ### Backward Compatibility We plan to release this multi-datasource support as an experimental feature with OpenSearch 3.0. OpenSearch Dashboards admins will be able to enable or disable the multi-datasource feature using configurations in `opensearch_dashboards.yml` . -If multi-datasource is enabled, OSD users will be able to see all data source related feature and APIs, that they can manage their data sources, and build visualization and dashboards with data sources. While if multi-datasource is disabled, users will not see anything related to data sources, and their OSD experience will remain the same as single data source. +If multi-datasource is enabled, OpenSearch Dashboards users will be able to see all data source related feature and APIs, that they can manage their data sources, and build visualization and dashboards with data sources. While if multi-datasource is disabled, users will not see anything related to data sources, and their OpenSearch Dashboards experience will remain the same as single data source. -If OSD admin enables multi-datasource for an existing OSD service, users will still able to use their existing index patterns and visualizations, which will by default fetch data from the same endpoint as their metadata store. +If OpenSearch Dashboards admin enables multi-datasource for an existing OpenSearch Dashboards service, users will still able to use their existing index patterns and visualizations, which will by default fetch data from the same endpoint as their metadata store. -If an OSD service has enabled multi-datasource, and it already has index pattern with remote data source created, admin will not able to disable multi-datasource feature. OSD will fail to start if it detected data source in the saved object while multi-datasource is disabled. +If an OpenSearch Dashboards service has enabled multi-datasource, and it already has index pattern with remote data source created, admin will not able to disable multi-datasource feature. OpenSearch Dashboards will fail to start if it detected data source in the saved object while multi-datasource is disabled. ### Security #### Data source access control -Multi-datasource project doesn’t plan to change the security (authN & authZ) controls for OSD. The `data-source` is a new type of saved objects, so the access control of `data source` will follow the same way as other saved objects such as index patterns and visualizations. +Multi-datasource project doesn’t plan to change the security (authN & authZ) controls for OpenSearch Dashboards. The `data-source` is a new type of saved objects, so the access control of `data source` will follow the same way as other saved objects such as index patterns and visualizations. -Based on existing OpenSearch and OSD security implementations, OSD saved objects access control is implemented via `security tenants`. OpenSearch users are mapped to a set of roles, and each role has corresponding permission to access certain tenants. If a user has permission to access a tenant, they will be able to access all saved objects in that tenant. With this mechanism, if a user created a data source in a shared tenant, other users who has access to that shared tenant will be able to see the data source object and see/create visualizations with the data source. +Based on existing OpenSearch and OpenSearch Dashboards security implementations, OpenSearch Dashboards saved objects access control is implemented via `security tenants`. OpenSearch users are mapped to a set of roles, and each role has corresponding permission to access certain tenants. If a user has permission to access a tenant, they will be able to access all saved objects in that tenant. With this mechanism, if a user created a data source in a shared tenant, other users who has access to that shared tenant will be able to see the data source object and see/create visualizations with the data source. #### Data source credential handling -Credentials is part of the data source object, and will be saved in OSD metadata index. OSD will use that credentials to authenticate with the data source when executing queries. This credentials will need to be encrypted regardless OSD has access control or not. +Credentials is part of the data source object, and will be saved in OpenSearch Dashboards metadata index. OpenSearch Dashboards will use that credentials to authenticate with the data source when executing queries. This credentials will need to be encrypted regardless OpenSearch Dashboards has access control or not. -We will use a symmetric key to encrypt the credentials before saving data source into OSD metadata index, and use the same key to decrypt it when OSD needs to authenticate with corresponding data source. For open source release, we will allow admins to configure the encryption key in the `opensearch_dashboards.yml` file. And we will also provide the option to integrate with a key store, such as AWS KMS, to use keys with the key store. +We will use a symmetric key to encrypt the credentials before saving data source into OpenSearch Dashboards metadata index, and use the same key to decrypt it when OpenSearch Dashboards needs to authenticate with corresponding data source. For open source release, we will allow admins to configure the encryption key in the `opensearch_dashboards.yml` file. And we will also provide the option to integrate with a key store, such as AWS KMS, to use keys with the key store. For more about credential encryption/decryption strategy, refer to [#1756](https://github.com/opensearch-project/OpenSearch-Dashboards/issues/1756) #### Auditing -As part of the security effort, OSD needs to support the logging for all use of data sources, so that admins can have a clear view of which OSD user accessed data source, and queried data from that data source. The audit log could be saved in the metadata store, or local logs for potential auditing work. +As part of the security effort, OpenSearch Dashboards needs to support the logging for all use of data sources, so that admins can have a clear view of which OpenSearch Dashboards user accessed data source, and queried data from that data source. The audit log could be saved in the metadata store, or local logs for potential auditing work. diff --git a/src/plugins/data_source/docs/user_stories.md b/src/plugins/data_source/docs/user_stories.md index 6601c477d8dd..40b60f8888f9 100644 --- a/src/plugins/data_source/docs/user_stories.md +++ b/src/plugins/data_source/docs/user_stories.md @@ -1,32 +1,32 @@ # OpenSearch Dashboards Multiple OpenSearch Data Source Support User Stories -Today, OpenSearch Dashboards (OSD) can only connect to one single OpenSearch cluster by configuring the cluster endpoint in the `opensearch_dashboards.yml` config file. We want to allow OSD users to dynamically add/update/remove OpenSearch compatible endpoints, and then do their analytics work with data in those OpenSearch data stores. +Today, OpenSearch Dashboards (OpenSearch Dashboards) can only connect to one single OpenSearch cluster by configuring the cluster endpoint in the `opensearch_dashboards.yml` config file. We want to allow OpenSearch Dashboards users to dynamically add/update/remove OpenSearch compatible endpoints, and then do their analytics work with data in those OpenSearch data stores. RFC: https://github.com/opensearch-project/OpenSearch-Dashboards/issues/1388 -This document discusses the user experience of the OSD multiple data source support. +This document discusses the user experience of the OpenSearch Dashboards multiple data source support. ## User Story ### Current user experience -- OpenSearch Dashboards admin setup the OSD service and configure the OpenSearch endpoint in `opensearch_dashboards.yml` - - Both the OSD metadata index (`opensearch_dashboards` index) and data indices are saved in the same OpenSearch cluster -- OSD users can work with visualizations, usually they will +- OpenSearch Dashboards admin setup the OpenSearch Dashboards service and configure the OpenSearch endpoint in `opensearch_dashboards.yml` + - Both the OpenSearch Dashboards metadata index (`opensearch_dashboards` index) and data indices are saved in the same OpenSearch cluster +- OpenSearch Dashboards users can work with visualizations, usually they will - Create/update index patterns - Create/update visualization, each visualization is built on top of one index pattern - Create/update dashboard using a group of visualizations - Run adhoc queries against an index pattern using discover feature - View index patterns/visualization/dashboards -- OSD users can work with analytics functions, such as Alerting/AD etc +- OpenSearch Dashboards users can work with analytics functions, such as Alerting/AD etc ### Expected user experience with multiple data source We are planning to introduce a new `data-source` model, to describe an OpenSearch data source, and letting index pattern to refer to a `data-source`. -- OpenSearch Dashboards admin setup the OSD service and configure the OpenSearch **metadata store endpoint** in `opensearch_dashboards.yml` +- OpenSearch Dashboards admin setup the OpenSearch Dashboards service and configure the OpenSearch **metadata store endpoint** in `opensearch_dashboards.yml` - the metadata store OpenSearch cluster only saves the `opensearch_dashboards` index, data indices can be saved in other OpenSearch stores -- Users will need to have a data-source before they can do any visualization or analytics work with OSD +- Users will need to have a data-source before they can do any visualization or analytics work with OpenSearch Dashboards - Users can create/update/view data sources - Users need to specify a data source when creating new index patterns, data source is not mutable after index pattern is created - Create/update visualization and dashboards experience remains the same as is today. @@ -35,7 +35,7 @@ We are planning to introduce a new `data-source` model, to describe an OpenSearc ## UI Change -This multiple data source support and introduction of data source model requires several UI changes on OSD +This multiple data source support and introduction of data source model requires several UI changes on OpenSearch Dashboards ### Data source management @@ -60,7 +60,7 @@ Credential management is provided way for user to add/edit/remove the credential - Index pattern creation flow: With the data sources, users will need to specify which data source to use when creating a new index pattern. - Index pattern detail page: On the index pattern detail page, we will need to show which data source this index pattern uses -- Data source selector for plugins: when OSD users working with analytics functions like Alerting and AD, we will want to allow users to switch between data sources +- Data source selector for plugins: when OpenSearch Dashboards users working with analytics functions like Alerting and AD, we will want to allow users to switch between data sources ## Appendix @@ -68,6 +68,6 @@ Credential management is provided way for user to add/edit/remove the credential For the initial launch with OpenSearch 3.0 preview, we do not plan to change security design of OpenSearch. -Users need to provide endpoint URL, username and password when creating a data source. OSD service will encrypt the username and password when storing it into metadata store. +Users need to provide endpoint URL, username and password when creating a data source. OpenSearch Dashboards service will encrypt the username and password when storing it into metadata store. -Data source is a new type of OSD saved objects. In current OpenSearch security model, access control on data source document is the same as other saved objects documents. Basically data source docs will be accessible by any user who has access to the tenant. +Data source is a new type of OpenSearch Dashboards saved objects. In current OpenSearch security model, access control on data source document is the same as other saved objects documents. Basically data source docs will be accessible by any user who has access to the tenant.