December 7, 2022, 4:56pm
[Proposal] Consolidated Dev Tools
There are multiple ways to query OpenSearch within OpenSearch (e.g. Dev Tools, Query Workbench). To make it less complicated and drive adoption for a variety of querying methods offered in OpenSearch, we want to build a central location to make querying for Admins in OpenSearch easy.
The team would appreciate the community’s comments and feedback on this.
10:59PM - 05 Dec 22 UTC
**Is your feature request related to a problem? Please describe.**
… multiple ways to query OpenSearch within OpenSearch (e.g. Dev Tools, Query Workbench). To make it less complicated and drive adoption for a variety of querying methods offered in OpenSearch, we want to build a central location to make querying for Admins in OpenSearch easy.
**Describe the solution you'd like**
To have one admin querying workbench experience where admins can query OpenSearch in the language that they are most familiar with.
* When troubleshooting an OpenSearch cluster or data within the cluster, an admin wants a central place to quickly troubleshoot and develop queries using languages they are familiar with, so that they can quickly find out what is going on with their system.
* When learning about a new query interface, admins will want to use a search and results interface which feels similar to other query interfaces in the tool, so that they don’t have to learn a new way of doing things.
* When revisiting a query interface, an administrator wants to select/save x previously run queries, so that they don’t waste their time recalling popular queries.
* When someone from compliance wants to see what queries have been run on OpenSearch, an administrator of OpenSearch wants to be able to show what queries have been run.
* When coming upon schema structures which are not familiar, an admin will want to explore the possible data structures, so that they can build the right query with confidence.
* When constructing new queries, a novice user will want quick access to documentation/examples/help on how to construct queries, so that they can learn as they go and feel confident in the project.
* When constructing a query incorrectly, all users want to be told why the query isn’t executing, so that they can fix their mistakes and move on (e.g. EXPLAIN)
* When constructing queries, performance conscious users and cluster administrators want to understand how the query could be written more efficiently, so that they can avoid taking up critical cluster resources.
**Describe alternatives you've considered**
Leaving the different ways to query OpenSearch as is.
Mockups to come soon.
February 13, 2023, 5:51pm
Looks like there’s some feedback on this on GitHub -
@jdbright - curious, how long are we keeping the proposal open?
@kris, I think we are ready to close the proposal at this point.