Thanks for bringing this discussion Benjamin. I raised a similar point in CASSANDRA-16725 <https://issues.apache.org/jira/browse/CASSANDRA-16725> and it may become a recurrent topic now the code freeze is lifted and more contributors will want to add new administrative commands to nodetool so it's important that we discuss and decide a consistent approach to this transition moving forward.
I was planning to write a CEP to propose a migration strategy from JMX to Virtual tables but since this discussion came before I will detail my thoughts so far. I think that we should add new commands exclusively to Virtual Tables and progressively migrate existing nodetool/JMX commands to VirtualTables/CQL until we ultimately get rid of JMX/nodetool. Nevertheless, from the user point of view it may be inconvenient/confusing to have administrative commands split between different interfaces so we need to think about this transition carefully to provide the best possible user experience. My motivation for CASSANDRA-16513 < https://issues.apache.org/jira/browse/CASSANDRA-16513> was that we're already providing some functionalities exclusively via Virtual Tables, so these features may not be visible to non-power users which are accustomed to the nodetool CLI interface for admin commands. The original plan for that ticket was to make nodetool abstract away the underlying interface (JMX, CQL) for administrative commands, so we would expose admin functionality via the same CLI interface (nodetool) to users while progressively migrating the backend from JMX to CQL/VirtualTables. Some people raised the concern that this could cause confusion among users about which credentials to use if JMX or CQL for nodetool. Based on this feedback I adapted the proposal to create an entirely different administrative CLI tool (which I called admintool) to access/modify virtual tables. In this proposal new administrative commands would be added exclusively to Virtual Tables and would automatically land on this tool, and legacy nodetool commands (via JMX) would be progressively migrated to admintool (CQL/VT) until the migration is completed. The drawback of this alternative proposal is that it would still split administrative commands between different CLI tools. So, if we decide to stop adding new admin functionality to JMX we have a few options to make this transition smoother for our users: 1) Do nothing and tell users some admin functionalities will be accessible exclusively via cqlsh/virtual tables - imo this option is the least user-friendly. 2) Make nodetool hybrid and provide a consistent interface to users while abstracting away the backend (JMX/CQL) 3) Create a new CLI tool (admintool) to provide CLI access to virtual tables and tell users to use both nodetool and admintool. I personally think option 2 is the least disruptive to users during the transition phase since people are already used to using nodetool so we can provide a seamless transition to JMX while keeping the CLI tool for legacy users. Even though there are concerns of confusion of which credentials to use on nodetool if we support both interfaces, we can make sure this is well documented. Em qui., 15 de jul. de 2021 às 09:35, Benjamin Lerer <ble...@apache.org> escreveu: > Hi everyone, > > When Virtual Tables/System Views were introduced in 4.0 it was with the > intention to provide a more friendly way than JMX and NodeTool to manage > and monitor nodes. > > In CASSANDRA-16404 <https://issues.apache.org/jira/browse/CASSANDRA-16404 > >, > Sam raises the point that it might make sense from now on to stop adding > functionalities to NodeTool and to provide them through Virtual Tables. > My initial feeling was that we could provide both until we decided to > deprecate NodeTool but that would require some extra work and as such might > not be a good strategy. > > What is your opinion on this? >
