> 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.
Agree, I don’t see the reason for a feature branch… feature branch just means the branch lives in apache domain rather than your own fork. You won’t be able to merge until you are done and you will need to keep rebasing over and over again. Even if multiple people are working on this you can work in your fork just fine (assuming you grant permissions). Another issue is that feature branches require the same level of commit process as every other main branch, where as personal branches don’t. This actually will slow you down as each commit now must be a JIRA, you go through review of each, must show a success CI, etc. Now, if you wish to split this into multiple steps that is fine, but the list of places is basically node tool (kinda has to go in at once) and small CLIs. If you wish to migrate the small ones in isolation first, I am cool with that merging to w/e branch the logic is targeting, but you won’t be able to break up node tool without breaking everything… but if you did this in your own fork then no one cares. I won’t block a feature branch, but just don’t see a clear “why” and only see cons. > We are changing the command markup library, so there are two extra > things to be checked: > - We parse CLI arguments in the same way (as the parser is different > in a new library); > - The command help output is the same so that the user won't see any > difference; Personally I would POC a limited node tool change with JVM dtest as we require passing the output to the test (the prototypes you listed doesn’t include JVM Dtest integration). If one library makes this more annoying, then do we care about fancy new features we don’t use when it makes the features we do use harder? If you start with the smaller tools first then spend a ton of time migrating node tool then find JVM dtest is broken, then you will spend so much more time fixing this, I would strongly recommend doing some throw away POC to make sure w/e way you go won’t break JVM Dtest’s node tool support. Once you are fine with your selected library, we will need a DISCUSS thread to add that new library (current protocol). This mostly just makes the pick more visible, and normally we only check simple things like “are we legally allowed to use” and “is this project dead?”. > On Jul 3, 2024, at 6:06 AM, Maxim Muzafarov <mmu...@apache.org> wrote: > > Thank you all for your comments, > > I want to stress, that these changes won't affect the input/output > formatting of commands, ensuring everything is the same. > > We are changing the command markup library, so there are two extra > things to be checked: > - We parse CLI arguments in the same way (as the parser is different > in a new library); > - The command help output is the same so that the user won't see any > difference; > > Additional tests cover both cases. > > On Mon, 1 Jul 2024 at 20:08, Dinesh Joshi <djo...@apache.org> wrote: >> >> 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
