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  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  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.

   
  
 

Config docs committed

[Ekaterina Dimitrova]

Hi all,
Just wanted to mention for awareness that the new config docs I promised
already landed in trunk.
There were too many discussions, changes and reviews in time around
CASSANDRA-15234 so I tried to consolidate all details at one place which
everyone can easily refer to.

Please let me know if you have any questions. I am available in Slack

Hope everyone has a nice weekend.

Best regards,
Ekaterina