Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

> Can be accomplished by updating or inserting on the settings virtual table via UPDATE system_views.settings SET value = 32 WHERE name = 'compaction_throughput'; Oh nice, I wasn't aware this was available already, this is a great feature to look forward to in 4.0! > There is a long way to

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

> a) Allow VirtualTables to be settable - to support changing parameters (ie. > nodetool setcompactionthroughput 32). Can be accomplished by updating or inserting on the settings virtual table via UPDATE system_views.settings SET value = 32 WHERE name = 'compaction_throughput'; INSERT INTO

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

I would say just go with it. JMX isn’t quite deprecated yet, and if we ever even end up doing that, it’s not going to be any time soon. > On 16 Jul 2021, at 13:32, Stefan Miklosovic > wrote: > > Thanks Benjamin for the understanding, but in the end, let's put aside > the frustration here, I

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

That's a good point. It seems to be able to fully deprecate JMX we will need the following: a) Allow VirtualTables to be settable - to support changing parameters (ie. nodetool setcompactionthroughput 32). b) Support CALL/EXECUTE/INVOKE CQL statements for things like flush and compact etc. When

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

> It seems only fair to me to let these patches go in and simply thank the contributors for their efforts and work. We can open some followup tickets for providing those functionalities through Virtual Tables (we are only talking about 2 patches). If nobody else takes them, I will. +1 Sounds like

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

Thanks a lot for all the feedback, I really appreciate the discussion and Paulo's proposals. Regarding the ongoing patches: Based on the discussion, it clearly appears that nodetool will still be there for some time (and will be there in the next major release). As such, it seems to me that the

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

> > > Until CEP exists and is approved, work on patches in flight seems > reasonable and valid. > > This is right, but when there is an active discussion about changing the > status quo it's polite to wait for the outcome of the discussion - or help > it make progress - before making potentially

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

> You lost me at "without requiring the user to provide CQL credentials" This is to address Jeremiah's concern of requiring users to provide different sets of credentials (JMX, CQL) to use nodetool, which can be an operational pain to users. I fail to see what's your concern here, since this

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

Thank you, I will proceed with my patch. On Thu, 15 Jul 2021 at 22:29, Jeff Jirsa wrote: > > Agreed. Status quo is status quo. If someone wants to change status quo, > CEP would be appreciated. > > Until CEP exists and is approved, work on patches in flight seems > reasonable and valid. > > > On

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

Agreed. Status quo is status quo. If someone wants to change status quo, CEP would be appreciated. Until CEP exists and is approved, work on patches in flight seems reasonable and valid. On Thu, Jul 15, 2021 at 12:38 PM J. D. Jordan wrote: > I see no problem with continuing to add JMX

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

On Thu, Jul 15, 2021 at 12:59 PM Brandon Williams wrote: > On Thu, Jul 15, 2021 at 8:59 AM Paulo Motta > wrote: > > > > Perhaps one approach to expose VirtualTables via nodetool without > requiring > > the user to provide CQL credentials would be to provide a generic > >

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

As long as the implemented nodetool commands are still going over JMX I see no issue. The problem lies when you need native transport access. In a secured cluster you possibly need an entirely new set of access information (username, password, ssl certificate) depending on how JMX access and

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

On Thu, Jul 15, 2021 at 8:59 AM Paulo Motta 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.

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

> I see no problem with continuing to add JMX commands for the foreseeable future. >From what I understood, Sam's proposal, to which I agree, is to entirely avoid adding new functionality to the JMX interface moving forward but just to VirtualTables, in order to avoid requiring new functionality

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

This is coming from the "JMX needs to die in a fire" guy, but I think Nodetool needs to stay as-is in 4.x. This is a massive breaking change for operators which fits into the major version issue requirements. Also, this should probably be a CEP. Patrick On Thu, Jul 15, 2021 at 12:07 PM Stefan

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

I see no problem with continuing to add JMX commands for the foreseeable future. > On Jul 15, 2021, at 2:07 PM, Stefan Miklosovic > wrote: > > Can I have a clear response from you, community, if my work on 16725 > is rendered totally useless in the light of this discussion? The time > on that

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

Can I have a clear response from you, community, if my work on 16725 is rendered totally useless in the light of this discussion? The time on that was already spent and I honestly can not see why it would be a problem to merge that command in. I am particularly objecting to Paulo's idea about

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

> > > What is your opinion on this? > This discussion was touched when implementing Diagnostics Events, at least the discussion of JMX vs native (rather than nodetool vs cqlsh). At that time JMX was chosen because there was no way for a client to specify the host you wanted the information

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

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 wrote: > > There's a tactical issue, too, that virtual tables require native transport > to be up before it's usable, so

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

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,

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

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

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

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

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

Thanks for bringing this discussion Benjamin. I raised a similar point in 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

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

On Thu, Jul 15, 2021 at 8:09 AM Stefan Miklosovic wrote: > Hence what I would like to do is to add 16725 as the last command ever > in nodetool and after that we might just make a big fat line and we > might slowly transition to a new system on virtual tables. I would really like to avoid the

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

Hi Benjamin, I was discussing this closely with Paulo some time ago, you may have already read the other email about this topic when I was talking about what we wanted to do with a GSOC student. I just can not find it for now ... In general I agree that we might slowly drift away from nodetool

[DISCUSS] Virtual Tables and the future of NodeTool/JMX

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 , Sam raises the point that it might make