[PROPOSAL] Dashboards Desktop MVP

[seraphjiang]

What kind of business use case are you trying to solve? What are your requirements?

We are going to bring native desktop experience to OpenSearch Dashboards user.

What is the problem? What is preventing you from meeting the requirements?

• It is difficult for Dashboards to customize (Dashboards settings) and extend (Plugins) their Dashboards
• There is no way to use one desktop connect to different OpenSearch endpoint
• Customer could not choose whichever version they want, update whenever they want

What are you proposing? What do you suggest we do to solve the problem or improve the existing situation?
Create desktop app which run OpenSearch Dashboards local and connect to 9200 port on localhost. 9200 doesn't has to run OpenSearch, it could proxy from other endpoint.

Mandatory (v1.0)

• Locate and run dashboards from specific location on disk
• Build in proxy service to connect to OpenSearch endpoint
• Home UI to allow user to select/configure OpenSearch endpoint
  -- support connect to AWS OpenSearch

Nice to have (v2.0)

• Management UI to install and uninstall plugins
• Management UI to customize OpenSearch Dashboards settings
• Detect latest snapshot/release version
• Download/update snapshot/release version

What are your assumptions or prerequisites?

• Authentication is out of scope of initial release
• Dashboards Desktop runs on 5601
• Dashboards use fixed version before we have capability to update
• A local sidecar proxying remote OpenSearch to 9200 localhost

What are remaining open questions?
List questions that may need to be answered before proceeding with an implementation.

** Key Scenarios **

1. User download Desktop App from downloads.opensearch.org (http://downloads.opensearch.org/) , launch on their desktop. User choose to run without signin. User is promoted to configure datasource they want to connect to and credential. e.g. AWS OpenSearch endpoint.

2. Once user configured and connected to support datasource, user could start to use Desktop App. User could install any plugins they want from plugins.opensearch.org (http://plugins.opensearch.org/) (open, free), local plugin

3. Desktop App will check update-feeds.opensearch.org (http://update-feeds.opensearch.org/) to detect if there is new desktop version app running

4. User could update dashboards without update Desktop App

5. User could remove/install/update dashboards plugins without update Desktop App

6. User could export/import save object from local disk/cloud to backup their data. In the future, they could share the save object to others, all reference link will be convert to accessible absolute link or relative link

[johnnyon-amzn]

A few questions about the parameters:

1. Which version of OSD are we starting with?
2. How is the proxy service managed, or does it just run in the background?
3. Can this app be run for local versions of OSD?

[seraphjiang]

1. Which version of OSD are we starting with?
   we could start with 2.0

2. How is the proxy service managed, or does it just run in the background?
   It is a lightweight http server.
   e.g. https://github.com/abutaha/aws-es-proxy

3. Can this app be run for local versions of OSD?
   It is design to be host environment for local OSD instance

[ZilongX]

1. Does this mean end users now have chances to customize their settings and store the config on their local ? If so will the config still be exposed as is (like kibana.yml) or in a new defined way (better GUI maybe) ?
2. "use one desktop connect to different OpenSearch endpoint" -> Would version matching be a concern, say local desktop OSD 1.3 vs remote Opensearch endpoint 1.1.

[seraphjiang]

1. Does this mean end users now have chances to customize their settings and store the config on their local ? If so will the config still be exposed as is (like kibana.yml) or in a new defined way (better GUI maybe) ?

Yes, user is able to customized settings in yml config file. we should provide a friendly UI to support it.

2. "use one desktop connect to different OpenSearch endpoint" -> Would version matching be a concern, say local desktop OSD 1.3 vs remote Opensearch endpoint 1.1.

That will be scope of Singe Dashboards program. to allow Dashboards compatible with all version of OpenSearch and Elasticserach

[ashwin-pc]

I'm having difficulty understanding why a desktop solution is needed to solve the issues mentioned in the problem statement. None of the issues seem to be a limitation of a web based approach.

1. "It is difficult for Dashboards to customize (Dashboards settings) and extend (Plugins) their Dashboards"
   What settings or plugin extensions are not possible using the web based model we have today?

2. "There is no way to use one desktop connect to different OpenSearch endpoint"
   Yan has demonstrated using a proof of concept that this is possible. It does not exist today yes but i'm not sure why we need a desktop interface to make this work

3. "Customer could not choose whichever version they want, update whenever they want"
   By customers do you mean users? because we do not automatically update dashboards right now. It is only coupled to the version of OpenSearch that they want to use.

[seraphjiang]

I'm having difficulty understanding why a desktop solution is needed to solve the issues mentioned in the problem statement. None of the issues seem to be a limitation of a web based approach.

1. "It is difficult for Dashboards to customize (Dashboards settings) and extend (Plugins) their Dashboards"
   What settings or plugin extensions are not possible using the web based model we have today?

there are two type of users in scenario OSD is hosted as web application.
Admin user who setup, run and maintain the instance
End User who use the OSD functionality

End user doesn't have any options to customize config like *elasticsearch.requestTimeout, server.maxPayloadByte
End user doesn't have any options to install plugins they want.
https://github.com/robcowart/kibana_plugins_list

2. "There is no way to use one desktop connect to different OpenSearch endpoint"
   Yan has demonstrated using a proof of concept that this is possible. It does not exist today yes but i'm not sure why we need a desktop interface to make this work

we want to provide customer options to connect to any data source, even local database access, excel, on-prime instance

3. "Customer could not choose whichever version they want, update whenever they want"
   By customers do you mean users? because we do not automatically update dashboards right now. It is only coupled to the version of OpenSearch that they want to use.

we will give customer the options to choose whatever major, minor, patch version or even dev build as they like

[ashwin-pc]

End user doesn't have any options to customize config like *elasticsearch.requestTimeout, server.maxPayloadByte

The end user does not have the ability to customize the config today yes, but the config is simply a object. We can easily have similar to the security model, configs for each user that default to the global config when custom overrides arent present right?

End user doesn't have any options to install plugins they want.

plugins will be a lil trickier but i believe we can implement something similar. The difficulty however will be in ensuring that one users plugin does not have access to another users data.

we want to provide customer options to connect to any data source, even local database access, excel, on-prime instance

Ah local database. Yes this will be a problem with NAT

we will give customer the options to choose whatever major, minor, patch version or even dev build as they like

I assume this will be using different executables

The usecase for a desktop client makes more sense to me now, might be worthwhile to explicitly call out these limitations in the original problem statement.

[seraphjiang]

We call this MVP not full product view. we want to ship the essential benefit in MVP first.
there are always overlap between online service and native desktop app, each of them has own strengths. like vscode desktop vs vscode online