I don't personally think there is a strong need for a feature branch. If it makes it easy for you, please go ahead with a feature branch.
One thing I had raised in the past was the desire to have a flag that would generate machine readable output for nodetool commands. If this can be done with a minor incremental effort, it would definitely reduce the burden on operators / integrations that rely on the nodetool output. As I have earlier indicated in the past, relying on human readable output for CLI tools like nodetool is fragile and providing a JSON output as an alternative is a great first step in eliminating that dependency. I'm just curious about the level of effort. If it is too much or too invasive, we can consider producing JSON output for inclusion in the next major release. On Fri, Jun 28, 2024 at 6:47 AM Maxim Muzafarov <mmu...@apache.org> wrote: > 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 >
