Perhaps one approach to expose VirtualTables via nodetool without requiring the user to provide CQL credentials would be to provide a generic StorageServiceMBean.queryVirtualTable(String name) JMX method returning a TabularData result. This would allow to keep a consistent nodetool frontend to users while progressively switching the backend from JMX to VirtualTables.
We could create a framework to automatically expose a basic nodetool getter/setter command whenever a new virtual table is added, making the new feature visible to non-power nodetool users while requiring little additional effort from the VirtualTable implementor. When migrating commands from JMX to VirtualTables we could just update the legacy nodetool command implementation to access the virtual table via the generic StorageServiceMBean.queryVirtualTable(String name) method while keeping the output consistent with the previous implementation, and deprecating their JMX counterpart. Ultimately when all commands are migrated from JMX to VirtualTables we could decide if we want to keep the nodetool CLI, acessing all virtual tables via the generic JMX virtual table accessor, or to deprecate nodetool altogether and tell users to query virtual tables directly via cqlsh instead. Em qui., 15 de jul. de 2021 às 10:34, Paulo Motta <pauloricard...@gmail.com> escreveu: > 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? >> >
