I am not for or against replacing… > I'm talkingabout CEP-38 [1], where I want to reuse the NodeTool commands and > execute them via CQL
> 1. So the first requirement that airline doesn't fulfil is to allow us > to stay aside from all API-specific options of the commands and only > use them where they are needed. Options such as port, host, username, > password-file are only JMX-related and shouldn't be part of the > command hierarchy in a broader sense. The airline doesn't give us a > way to use them dynamically only for cli. Given your example of Nodetool I don’t feel this is a valid argument. We override Nodetool in JVM Dtest and can avoid such a problem (reject anyone using these). > > 2. The second point you mentioned is that as long as the obsolete > library is doing its job for the cli and doesn't contain any CVE > risks, there is no need to replace it. However, if we want to reuse it > in other APIs, it just doesn't make sense to build new CQL/JMX > adapters on top of obsolete annotations and a library has to be > updated. These are my personal feelings. We also must weigh the risk of stability… Changing something for the sake of changing it may get past all our CI then could break a user as they used something we were not aware was being done (return codes, stdout/stderr, etc.); replacing something public facing comes with massive risk. > it just doesn't make sense to build new CQL/JMX > adapters on top of obsolete annotations and a library has to be > updated I don’t follow this argument… why would we need to change libraries to get Nodetool to work in CQL? I have not read the CEP or tickets for this work, but if we were doing something like cqlsh > nodetool repair mykeyspace tbl -pr; We could do what we did in jvm-dtest and replace the main method…. Why do we even care about annotation processing or libraries? > > 3. And the third and least important point, if we are not concerned > about CVEs (I assume the risks are really low in this case), by not > updating the obsolete dependency we are limiting the number of > integrations that the project could have. Popular and well-known > libraries provide many integrations out of the box. Again, must weigh the risk vs the reward. Sure, we could have colored output, but if that breaks users was it worth it? > On Jul 16, 2024, at 9:01 AM, Caleb Rackliffe <calebrackli...@gmail.com> wrote: > > With concerns around licensing all but resolved, I'd support Pico as our > airline replacement. It looks like it would entail the least risky migration, > is being actively maintained, will make the development of a number of > planned enhancements easier, etc. > > On Tue, Jul 16, 2024 at 10:40 AM Jeff Jirsa <jji...@gmail.com > <mailto:jji...@gmail.com>> wrote: >> (Answering this as a cassandra person, don’t confuse this reply as >> board/foundation guidance) >> >> The legal landscape is rapidly evolving with the CRA. The answer may change >> in the future, but I think “we have a dependency we ship that’s >> user-accessible and known to be abandoned” is an unhappy state that’s >> indefensible if there’s ever a transitive dependency issue (e.g. log4j style >> “oh who would have guessed that was possible” ). >> >> I’d look at this slightly differently - if someone proposed adding this >> library right now, we’d all say no because it’s unmaintained. That alone >> should be enough justification to fix the obvious problem - if it’s >> unmaintained, let’s remove it before we’re doing it on fire. >> >> >> >> > On Jul 16, 2024, at 8:11 AM, Ariel Weisberg <ar...@weisberg.ws >> > <mailto:ar...@weisberg.ws>> wrote: >> > >> > Hi, >> > >> > I am pretty torn down the middle on this one. Unmaintained bad, but also >> > Aleksey is right. If there are few/no dependencies in airline then it >> > could be "done" given the narrow scope of what it does. >> > >> > It seems to depend on Guava, javax.inject, and findbugs. Seems like we can >> > probably update the dependencies on our end if there is a security issue. >> > >> > Can we get clarity from Apache legal on whether simply being unmaintained >> > will be something we are motivated to fix for legal reasons? >> > >> > If we have the code/prototype now (assuming we settle on Picocli), is the >> > counter argument "churn bad" as strong? I don't anticipate changing from >> > one to the other being too bad if someone else is footing the bill so to >> > speak. Especially if Maxim is willing to take the lead on any bugs that we >> > might uncover in the switch. >> > >> > Ariel >> > >> > On Mon, Jul 15, 2024, at 2:53 PM, Maxim Muzafarov wrote: >> >> Hello everyone, >> >> >> >> >> >> I want to continue the discussion that was originally started here >> >> [2], however, it's better to move it to a new thread with an >> >> appropriate title, so that everyone is aware of the replacement >> >> library we're trying to agree on. >> >> >> >> The question is: >> >> Does everyone agree with using Picocli as an airlift/airline >> >> replacement for our cli tools? >> >> The prototype to look at is here [1]. >> >> >> >> >> >> The reasons are as follows: >> >> >> >> Why to replace? >> >> >> >> There are several cli tools that rely on the airlift/airline library >> >> to mark up the commands: NodeTool, JMXTool, FullQueryLogTool, >> >> CompactionStress (with the size of the NodeTool dominating the rest of >> >> the tools). The airline is no longer maintained, so we will have to >> >> update it sooner or later anyway. >> >> >> >> >> >> What criteria? >> >> >> >> Before we dive into the pros and cons of each candidate, I think we >> >> have to formulate criteria for the libraries we are considering, based >> >> on what we already have in the source code (from Cassandra's >> >> perspective). This in itself limits the libraries we can consider. >> >> >> >> Criteria can be as follows: >> >> - Library licensing, including risks that it may change in the future >> >> (the asf libs are the safest for us from this perspective); >> >> - Similarity of library design (to the airline). This means that the >> >> closer the libraries are, the easier it is to migrate to them, and the >> >> easier it is to get guarantees that we haven't broken anything. The >> >> further away the libraries are, the more extra code and testing we >> >> need; >> >> - Backward compatibility. The ideal case is where the user doesn't >> >> even notice that a different library is being used under the hood. >> >> This includes both the help output and command output. >> >> >> >> Of course, all libraries need to be known and well-maintained. >> >> >> >> What candidates? >> >> >> >> >> >> Picocli >> >> https://picocli.info/ >> >> >> >> This is the well-known cli library under the Apache 2.0 license, which >> >> is similar to what we have in source code right now. This also means >> >> that the amount of changes (despite the number of the commands) >> >> required to migrate what we have is quite small. >> >> In particular, I would like to point out that: >> >> - It allows us to unbind the jmx-specific command options from the >> >> commands themselves, so that they can be reused in other APIs (my >> >> goal); >> >> - We can customize the help output so that the user doesn't notice >> >> anything while using of the nodetool; >> >> - The cli parser is the same as what we now do with cli arguments. >> >> >> >> This makes the library a good candidate, but leaves open the question >> >> of changing the license of the lib in the future. However, these risks >> >> are relatively small because the CLI library is not a monetizable >> >> thing, as I believe. We can also mitigate the risks copying the lib to >> >> sources, as it mentioned here: >> >> https://picocli.info/#_getting_started >> >> >> >> >> >> commons-cli >> >> https://commons.apache.org/proper/commons-cli/ >> >> >> >> In terms of licenses, it is the easiest candidate for us to use as >> >> it's under the asf, and in fact the library is already used in e.g. >> >> BulkLoader, SSTableExpoert. >> >> However, I'd like to point out the following disadvantages the library >> >> has for our case: >> >> - This is not a drop-in replacement for the airline commands, as the >> >> lib does not have annotation for markup commands. We have to flesh out >> >> all the options we have as java classes, or create our owns; >> >> - Subcommands have to be supported manually, which requires extra >> >> effort to adopt the cli parser (correct me if I'm wrong here). We have >> >> at least several subcommands in the NodeTool e.g. cms describe, cms >> >> snapshot; >> >> - Apart from parsing the cli arguments, we need to manually initialize >> >> the command class and set the input arguments we have. >> >> >> >> >> >> JComannder >> >> https://jcommander.org/ >> >> >> >> The library is licensed under the Apache 2.0 license, so the situation >> >> is the same as for Picocli. Here I'd like to point out a few things I >> >> encountered while prototyping: >> >> - Unbinding the jmx-specific options from commands is quite tricky and >> >> requires touching an internal API (which I won't do). Option >> >> inheritance is not the way to go if we want to have a clear command >> >> hierarchy regardless of the API used. >> >> - We won't be able to inject a Logger (the Output class in terms of >> >> NodeTool) or other abstractions (e.g. MBeans) directly into the >> >> commands, because it doesn't support dependency injection. This is >> >> also part of the activity of reusing the commands in other APIs, for >> >> instance to execute them via CQL; >> >> >> >> More basic in comparison to the Picocli, focusing primarily on simple >> >> annotation-based parsing and subcommands, and won't allow us to reuse >> >> the commands outside of the cli. >> >> >> >> >> >> airline2 >> >> https://github.com/rvesse/airline >> >> >> >> The library is licensed under the Apache 2.0 license, and this is an >> >> attempt to rebuild the original airline library. Currently, this is >> >> not a drop-in replacement, as it has some minor API differences from >> >> the original library. It is also not a better choice for us, as it has >> >> the same drawbacks I mentioned for the previous alternatives, e.g. not >> >> possible to unbind the specific options from the command and use them >> >> only when commands are called from the cli. >> >> >> >> >> >> >> >> >> >> [1] https://github.com/apache/cassandra/pull/2497/files >> >> [2] https://lists.apache.org/thread/m9wfb3gdo9s210824c9rm2ojc9qv9412 >>
