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
