We could eventually make a virtual table only mode to resolve this - not serve any data until a node is ready to do so - if necessary.
> On 15 Jul 2021, at 17:43, Jeff Jirsa <jji...@gmail.com> wrote: > > There's a tactical issue, too, that virtual tables require native transport > to be up before it's usable, so for things pre-startup (e.g. querying > streaming state during bootstrap), so I don't think nodetool/jmx dies > entirely ever (or, a non-client-facing-virtual-tables-only port has to be > created, but that's much more involved obviously) > > On Thu, Jul 15, 2021 at 9:18 AM Lorina Poland <lor...@datastax.com> wrote: > >> 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? >>>>> >>>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
