Re: [Discuss] replacement of airlift/airline framework in CLI tools

[Tibor Répási]

The current issue is that airlift/airline is deprecate. Having a deprecated dependency is not nice and a call for maintenance. By now, I don't known about any vulnerability or other issue that would call for urgent action. So, we are not in a hurry, event the version target 4.x should be considered stretchable.

Maintaining some other tools, originally inspired by nodetool, I started evaluating alternatives. Started with airline2 and picocli, my preliminary findings are

airline2:

+ low effort to replace, nearly unchanged API

+ capability to generate documentation

picocli:

- considerable effort for migration needed

+ more modern and lean API

+ capability to generate documentation

+ capability to generate shell-completion, including not just subcommands but all options and parameters

+ capability to generate man pages

In my opinion, there is room for improvement, especially on documentation and the usability of tools:

* more detailed descriptions on commands and subcommands

* better accessibility to help and docs, e.g. on the website, as man pages, etc.

* adding usage examples to docs and help

* doc pages on the website could be generated e.g. as a side-product of the release process

* the command completion script could be generated, without the need for manual maintenance and packaging

* coloured output in a terminal would be appreciated, especially by less experienced users, e.g. when looking at nodetool status on larger clusters

Many of the above are not supported by the current framework and would need considerable effort to implement. When we replace the framework, these, and probably more, should be considered and discussed.

As operator of several hundreds of Cassandra nodes I am aware of the importance of stability and I do have extensive tooling and automation wrapped around Cassandra tools as well. Breaking these would cause serious pain and could be a showstopper, even for major version changes. IMO, CLI and output doesn't necessarily need to change, even features like coloured output should be limited to interactive use only. Consider the replacement as a platform for future improvements, the opportunity to reduce complexity within the source code, automation of processes of documentation and auto-generated usability-helper.

Admittedly, my opinion is not unbiased, I alway tend to improvements when it comes to changes, rather than keeping the status quo.

Stefan Miklosovic <stefan.mikloso...@instaclustr.com> hat am 17.03.2022 21:42 geschrieben:

Hi Tibor,

Thanks for raising this.

Do you see some important issues you would like to address by

switching to a newer Airline or are we updating just because the

former version is not supported anymore? How much do you miss the new

Airline library and does the older library prevent you from achieving

something the newer one is able to deliver? Can you be specific?

I am used to picocli too, it is a very handy library, one class

actually. However, I am afraid that switching to anything else would

be quite a "shock" to users who are just used to good old & stable

stuff. People are parsing the output of this tooling in scripts and so

on. It is a very delicate matter. The output matters. This might be

probably something for 5.0, I do not think that having such a breaking

user-facing change would be appropriate to introduce in 4.1 or any

point release ...

Regards

On Wed, 16 Mar 2022 at 15:03, Tibor Répási <tibor.rep...@anzix.org> wrote:

>

In CASSANDRA-17445 we’ve started discussing the options of replacing the deprecated airlift/airline framework used in CLI tools.

Considering the amount of commands this framework is used in, the impact this might cause and the future possibilities the operational aspects of Cassandra could leverage, first comments at slack revealed an in-depth discussion would be desirable.

Kind request for comments.