Thank you, I will proceed with my patch. On Thu, 15 Jul 2021 at 22:29, Jeff Jirsa <jji...@gmail.com> 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 Thu, Jul 15, 2021 at 12:38 PM J. D. Jordan <jeremiah.jor...@gmail.com> > wrote: > > > I see no problem with continuing to add JMX commands for the foreseeable > > future. > > > > > On Jul 15, 2021, at 2: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 > > > > > > > --------------------------------------------------------------------- > > 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
