RFC: Unified OpenSearch Command Line Interface (opensearch-cli)

[VijayanB]

The purpose of this request for comments (RFC) is to introduce our plans to provide a unified command line tool (cli) for users to interact with OpenSearch. This RFC is meant to cover how we plan to integrate the SQL, PerfTop, and OpenSearch cli into one. We do not cover implementation details and architecture. We would like to collect feedback and discuss our plans with anyone interested.

Problem Statement

OpenSearch and its plugins adopted REST based mechanism for interaction. With more than 10 different and continuously evolving OpenSearch plugins, we think it is important to provide a unified command line interface to help people use these plugins from a single tool. Today, we have three different kind of command line interfaces, namely opensearch-cli, opensearchsql-cli and perftop-cli. These command line interfaces are hosted, built, released and distributed independently. As OpenSearch user, I have to download those three command line interface from three different place, update those CLI whenever new version is released individually and configure my preferences in multiple places.

Proposed Solution

We are planning to integrate all three cli into one universal cli, since, OpenSearch and its plugins are distributed together, it makes sense to integrate all three different command line interface and provide one binary artifact for our users to download and update at one place to get latest features.

These three different CLIs are meant for three different personas and they are carefully implemented by selecting the best framework choice for their users. Hence, we want to keep the essentials of individual CLI and provide one package/artifact for end user to download and use it.

We are proposing that different cli artifacts will be developed separately but shipped together as a part of one binary. Later, these different CLI will be invoked based on the wake word/sub command from opensearch-cli.

What does this look like for opensearchsqlusers?

$ opensearch-cli sql --profile foobar [enter]  
    ____                  _____                      __  
  / __ \____  ___  ____ / ___/___  ____ ___________/ /_ 
 / / / / __ \/ _ \/ __ \\__ \/ _ \/ __ `/ ___/ ___/ __ \
/ /_/ / /_/ /  __/ / / /__/ /  __/ /_/ / /  / /__/ / / /
\____/ .___/\___/_/ /_/____/\___/\__,_/_/   \___/_/ /_/ 
    /_/                                                 

Server: OpenSearch 1.0.0
CLI Version: 1.9.0.0
Endpoint: https://localhost:9200
`opensearchsql`> select * FROM

What does this look like for perftop users?

$ opensearch-cli perftop --profile foobar [enter]

This solution works well for following reasons

1. Users only need to download one CLI to use all of the functionality.
2. Some features like config files/configure cluster details can be shared.
3. With this approach it will take less development effort to merge these different CLI. This is because we will just be invoking existing artifacts without much code changes.

Providing Feedback

If you have comments or feedback on our plans for OpenSearch Command Line Interface, please add it here to discuss. Some other questions we’re seeking feedback include

1. Do you use package managers to install CLIs that you use? If so, which ones?
2. How would you expect versioning of our CLI line up with OpenSearch’s versioning? (it could be coupled or decoupled). We lean towards decoupling to keep things independent.

[elfisher]

I really like the idea of having a single installable with different modes based on the use case (i.e. SQL mode, PerfTop mode, etc). For the questions. on number 1, I'd be curious to see what people use. I think as a starting point hosting the installables on the website will be the most useful, but I can imagine Homebrew and apt could be useful to add at some point. For number 2 I definitely see some pros and cons to both approaches. Coupling the versions would make it easier to know with version of the CLI is compatible with which version of OpenSearch. However, each time we build a new minor version of OpenSearch, we would need to build and release a new version of the CLI, even if there isn't new functionality. Decoupling has the pros and cons reversed where the con is it might be harder to understand which versions are compatible with corresponding versions of OpenSearch. The pro is that these can move independently. I personally lean towards decoupling.

[janhoy]

Have you looked at how Git subcommands are designed? Looks very similar to your proposal. I like the simplicity of separate binaries in a predefined bin folder (or even on user's PATH), and a man page per sub command. It would not be a disadvantage if 3rd party plugins were able to install sub commands as well. You'd first install the plugin into opensearch, and then run another command if you also want to install a cli sub command.

[elfisher]

Thanks for sharing this @janhoy! I like the idea of being able to install subcommands under the main CLI. I'm now thinking if we had a common package manager/place to store the subcommand binaries, we could make the experience of installing them pretty simple; something like opensearch-cli -install <subcommand name> In lieu of that, I do like the Git approach you shared where you can drop a binary into a folder for the main CLI to pick up the subcommand binary.

[dblock]

This is a reasonable proposal, but it's clear from above comments that beyond gluing the clients together we want an extensibility framework, and that the framework is not reinvented but something established is reused. Another example, the meta project allows for plugins, such as meta-gh, which can be authored and installed on top of the meta CLI. Thus I'd expect that someone could author a plugin (e.g. sql) along with a client extension (e.g. sql-cli) and users can install sql-cli and be able to type opensearch-client sql ....

Additional thought: I would like some standardized parameters. I definitely would not want to have to specify --user when opensearch-cli sql vs. --username when opensearch-cli perftop.