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

[Tibor Répási <ti...@anzix.org>]

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.

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

[Tibor Répási <ti...@anzix.org>]

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.miklosovic@instaclustr.com](mailto:stefan.miklosovic@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.repasi@anzix.org](mailto:tibor.repasi@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.

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

[Dinesh Joshi <dj...@apache.org>]

airline/airlift is deprecated. I suspect if there were any security issues they would not be fixed. Their project recommends moving to Airline 2 or picocli.

I share Stefan's concern about the stability of the CLI and output formatting. We should avoid any breakages resulting from this migration. Lots of automation depends on this "interface" being stable.

> On Mar 17, 2022, at 1:42 PM, Stefan Miklosovic <st...@instaclustr.com> wrote:
> 
> 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 <ti...@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.

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

[Stefan Miklosovic <st...@instaclustr.com>]

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