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: [VOTE] Release Apache Cassandra 4.0.0 (take2)

+1 > On 13 Jul 2021, at 23:13, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 4.0.0 for release. > > sha1: 924bf92fab1820942137138c779004acaf834187 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative > Maven Artifacts: >

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

+1 Dinesh > On Jul 15, 2021, at 8:01 AM, Enrico Olivelli wrote: > > +1 > > - Run all tests with CDC > - Verified checksums and digital signatures > > Enrico > >> Il giorno gio 15 lug 2021 alle ore 16:59 Branimir Lambov < >> branimir.lam...@datastax.com> ha scritto: >> >> +1 >> >> On Thu,

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

+1 - Run all tests with CDC - Verified checksums and digital signatures Enrico Il giorno gio 15 lug 2021 alle ore 16:59 Branimir Lambov < branimir.lam...@datastax.com> ha scritto: > +1 > > On Thu, Jul 15, 2021 at 12:55 AM Scott Andreas > wrote: > > > +1nb. > > > > Thank you for sharing a

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

+1 On Thu, Jul 15, 2021 at 12:55 AM Scott Andreas wrote: > +1nb. > > Thank you for sharing a Circle run, Sumanth! > > > From: Sumanth Pasupuleti > Sent: Wednesday, July 14, 2021 12:52 PM > To: dev@cassandra.apache.org > Subject: Re: [VOTE] Release

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] CEP-10: Cluster and Code Simulations

Does anybody have some other concerns than the target date? If not, I believe that we can start a vote tomorrow. Le mer. 14 juil. 2021 à 23:18, Nate McCall a écrit : > > > > > > > > > Yes, we should perhaps remove target version from the template, and > > > introduce guidance on describing

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