> I personally don't have anything against what you suggested, however I think that this kind of work will put additional stress on us being sure that the output of the commands will be exactly as it is now. We do have nodetool tests which are covering the tests for the output which is very handy in this kind of situation, but I think we do not test all of them. It would be great to increase our test coverage where possible in this area and I think it is actually going to be a requirement as only then we will be sure that old and new code produces the same output.
I'm not familiar with picocli, only jcommander, however I don't think keeping the output consistent should be a problem as long as it's a similar programming model. I also don't think keeping the output consistent needs to be a strict long term requirement. We *should* have either a JSON output option for every command, or a virtual table for structured data. I don't remember us ever making a promise that human readable tools would keep consistent across major versions. On Mon, Jul 1, 2024 at 6:44 AM Bernardo Botella < conta...@bernardobotella.com> wrote: > +1 on the feature branch allowing breaking the effort into smaller chunks > that can be even worked in parallel. > > > > On Jul 1, 2024, at 3:13 AM, Štefan Miklošovič <smikloso...@apache.org> > wrote: > > Hi Maxim, > > thank you for doing this. I think that Picocli is a great choice, > comparing it with airline v2 which is an attempt to resurrect the original > airline, it seems to be way more active and popular. > > I personally don't have anything against what you suggested, however I > think that this kind of work will put additional stress on us being sure > that the output of the commands will be exactly as it is now. We do have > nodetool tests which are covering the tests for the output which is very > handy in this kind of situation, but I think we do not test all of them. It > would be great to increase our test coverage where possible in this area > and I think it is actually going to be a requirement as only then we will > be sure that old and new code produces the same output. > > I think it is too soon to contemplate when we switch to this, we just need > to be sure that it is the same so existing integrations will not be broken. > > Regards > > On Fri, Jun 28, 2024 at 3:48 PM 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 >> > >
