Hello everyone,
The nodetool relies on the airlift/airline library to mark up the CLI commands used to manage Cassandra, which are part of our public API. This library is no longer maintained, so we need to update it anyway, and the good news is that we already have several good alternatives: airline-2 [3] or picocli [2]. In this message, I'm mainly talking about CASSANDRA-17445 [4], which refers to the problem and is a prerequisite for a larger CEP-38 CQL Management API [5]. It doesn't make sense to use annotations from the deprecated library to build a new API, so this is another reason to update the library as soon as possible and do some inherently small code refactoring required for the CEP-38. In addition to being widely used and well supported, the Picocli library offers the following advantages for us: - We can detach the jmx-specific parameters from the commands so that they can be reused in other APIs (e.g. without host, port) while remaining backwards compatible; - We can set up nodetool's autocompletion after the migration with minimal effort; - There is a good Picocli ecosystem of tools that we can use to simplify our codebase, e.g. generate man pages tool to make our CLIs more Unix friendly [7]; = Prototype = I have a working prototype [8] that shows what the result will look like. The prototype includes: - Tests between the execution of commands via the nodetool and nodtoolv2; - 5 out of 164 nodetool commands have been moved so far, to show the refactoring we need to do to the command's body; - The command help output under for the nodetoolv2 is the same as it is currently for the nodetool and this is the default, however a "cassandra.cli.picocli.layout" is added to switch to the Picocli defaults; - You can also see that the colour scheme is applied by the Picocli out of the box, and this is how it looks [9]; - The nodetoolv2 is called first when the shell is triggered, and if the nodetoolv2 doesn't contain the command it needs yet, it falls back to the nodetool and the old argument parser; Since the number of commands is quite large (164), I'd like to create a feature branch and move all the commands one at a time, while keeping the output backwards by applying additional tests at the same time and checking that the CI is always green. I think the "feature branch" approach will be less stressful for us since it focuses on requiring a review of only tedious changes to the feature branch, rather than reviewing the 15k line patch. Anyway, I am open to any suggestions and advice based on your experience and best practices for this case. Looking forward to your thoughts and suggestions. [1] https://github.com/airlift/airline [2] https://picocli.info/ [3] https://github.com/rvesse/airline [4] https://issues.apache.org/jira/browse/CASSANDRA-17445 [5] https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API [6] https://github.com/apache/cassandra/pull/2497/files#diff-acdd5f29d28df5c02f4bfc933528f084508b4923112e312e68a4aff7df973bce [7] https://picocli.info/man/gen-manpage.html [8] https://github.com/apache/cassandra/pull/2497/files [9] https://github.com/apache/cassandra/assets/3415046/57b14ae0-ff59-43d2-b542-10d3218ae075
