I think it is important to keep in mind that users may be utilizing nodetool programmatically, in scripts. Obviously, those scripts could use calls to cqlsh as an alternative, but I'm a fan of keeping nodetool intact, building out virtual table capability, and then deprecating nodetool. In other words, only deprecate/remove nodetool commands once a *whole* replacement is available. And then deprecate slowly, perhaps with migration help in the docs for nodetool -> virtual tables.
Lorina On Thu, Jul 15, 2021 at 6:59 AM Paulo Motta <pauloricard...@gmail.com> wrote: > 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? > >> > > >
