> 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 to be added to both JMX and VirtualTable interfaces, creating user confusion, additional development burden and adding code we know it's going to be deprecated. I think we should first focus on deciding if we want to go through this path, before deciding what to do with in-progress JMX work such as Cassandra-16404 and CASSANDRA-16725. > 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. I don't think anybody is in favor of removing nodetool in 4.X. Please note that stopping adding new functionality to JMX does not mean killing nodetool. The transition proposal is: 1) Stop adding new stuff to JMX 2) Add new admin commands only to VirtualTables while exposing them via nodetool 3) Progressively migrate nodetool commands to virtual tables 4) Once all nodetool commands are migrated to virtual tables, in the next major, consider deprecating nodetool in a separate effort. > Also, this should probably be a CEP. I layed out on this thread a sketch transition proposal to keep the nodetool frontend unchanged while replacing it's backend progressively with VirtualTable, with zero user impact and would love to detail this into a CEP if there's community interest/support. Em qui., 15 de jul. de 2021 às 16:40, Patrick McFadin <pmcfa...@gmail.com> escreveu: > 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 Miklosovic < > stefan.mikloso...@instaclustr.com> 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 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 dropping JMX command > > implementations altogether, I find it quite radical without any > > meaningful justification except "wasting somebody's time" but since it > > is my time I spent on this, I am not sure why anybody would care? > > While I do understand that we are trying to move forward with cql and > > so on, I find it quite ridiculous to stop "5 minutes before 12" just > > because somebody happened to drop an email to the dev list about this > > before I managed to finish it. > > > > In other words, I find it just easier to finish it and voila, we can > > query audit's config, when we are super close to it and all who spend > > time on that was me - rather than waiting for weeks and months until > > this discussion settles, living without that until then. > > > > Regards > > > > On Thu, 15 Jul 2021 at 20:38, J. D. Jordan <jeremiah.jor...@gmail.com> > > wrote: > > > > > > I also am in favor of continuing to support nodetool in parallel with > > developing a command line tool and associated virtual tables to replace > > nodetool/JMX at some point in the future. > > > I don’t think “native transport is not currently available during > > startup” is something to halt progress towards this goal. There are many > > ways to change the system to make that a non-problem. But it is > something > > to remember while moving towards the goal of node management without > using > > JMX. > > > > > > -Jeremiah > > > > > > > On Jul 15, 2021, at 12:21 PM, Mick Semb Wever <m...@apache.org> > wrote: > > > > > > > > > > > >> > > > >> > > > >> > > > >> 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 from. Some more info in > CASSANDRA-13459 > > > > and CASSANDRA-13472. > > > > > > > > The java and python drivers have since added this functionality. But > if > > > > it's not widely adopted by all the drivers, and the functionality may > > have > > > > programmatic uses, this can be problematic. > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
