OT, but would gladly +1(nb) a `nodetool --output-format=json` CEP. :) [ Some discussion also in: https://issues.apache.org/jira/browse/CASSANDRA-12698 ]
> On Jul 8, 2023, at 11:26 AM, Josh McKenzie <jmcken...@apache.org> wrote: > >> I think they should not parse that output in the first place. Gradually >> introducing JSON / YAML output formats for nodetool is cool but I think it >> started to happen too late and people were already parsing the raw nodetool >> output and here we are. > Yes And: as you say: "here we are". > > I personally try and overcorrect on the side of "how do we make things easier > for our users" whenever I'm presented with the opportunity because we've > historically been so weak on the UX front as a project. Maintaining > compatibility with previous "API's" (as we've discussed on the ML in the > past; things that are publicly presented and consumable by automation) goes a > long way towards giving folks confidence in building an ecosystem around a > project. Not the most fun thing in the world to maintain, but IMO worth it in > the long run for the confidence it gives folks. Especially in the "long-lived > infra" space we're in. > > On Sat, Jul 8, 2023, at 12:57 PM, Miklosovic, Stefan wrote: >> If somebody understood my message as I am promoting the removal of all these >> commands for which we have other means of getting the output of, that is not >> the case at all. I do not want to remove any of them.. I am just elaborating >> on "parsing the output of nodetool and problems related to that if it is >> changed" in this particular case. >> >> ________________________________________ >> From: Miklosovic, Stefan <stefan.mikloso...@netapp.com >> <mailto:stefan.mikloso...@netapp.com>> >> Sent: Saturday, July 8, 2023 17:43 >> To: dev >> Subject: Re: Changing the output of tooling between majors >> >> Thank you, Josh, for your insight. >> >> I think they should not parse that output in the first place. Gradually >> introducing JSON / YAML output formats for nodetool is cool but I think it >> started to happen too late and people were already parsing the raw nodetool >> output and here we are. >> >> I played with nodetool a little bit to see where we are with this, there is >> 135 commands in total. We can leave out all "set*" commands, we can not >> ignore "get*" because that is potential output to parse. People just don't >> parse the output of "set*" commands. That is 116 commands. We can also >> ignore all "disable*" and "enable" commands and we are on 98. Then there is >> the group of "invalidate*" commands, we can skip them too, we are on 90, >> minus help command, 89. >> >> Now the commands which left can be categorized into two main groups: the >> commands which execute some action and commands which display some >> statistics or state about internals of a Cassandra node. >> >> The first group, "action commands", are again not going to be parsed on the >> output. These are here (1) (I could make some mistakes here and there). >> >> So, the commands we can potentially parse the output of are here (2), there >> is roughly 51 of them. >> >> Some of these commands have their equivalent in system_views vtables, these >> are, if I havent forgotten something >> >> clientstats (system_views.clients) >> compactionhistory (system.compaction_history) >> compactionstats (system_views.sstable_tasks) >> gossipinfo (system_views.gossip_info) >> listsnapshots (system_view.snapshots) >> tpstats (system_view.thread_pools) >> >> Some of them have already different format of the output supported (JSON or >> YAML), they are: >> >> datapaths >> tablestats >> tpstats (has also cql table) >> compactionhistory (has also cql table) >> >> I would argue that some commands with prefix "status" and "get" can go away >> too because their value is visible in system_views.settings. Some of these >> settings will be even updateable after Maxim's work. >> >> statusbackup incremental_backups >> statushandoff hinted_handoff_enabled >> getmaxhintwindow max_hint_window >> getconcurrentcompactors concurrent_compactors >> getconcurrentviewbuilders concurrent_materialized_view_builders >> getdefaultrf default_keyspace_rf >> gettimeout (this just reflects cassandra.yaml more or less) >> >> Then there is the family of all "get throttle / threshold " etc like this, I >> am lazy to go through them but they are somehow retrievable from CQL >> system_views.settings too. >> >> getbatchlogreplaythrottle >> getcolumnindexsize >> getcompactionthreshold >> getcompactionthroughput >> getinterdcstreamthroughput >> getsnapshotthrottle >> getstreamthroughput >> >> There are commands which just return an integer or there is nothing to >> change about their output / it is just not necessary like: >> >> gettraceprobability >> getsstables >> >> So commands which do not have their output equivalent in some cql table or >> for which there is not JSON / YAML format available are >> >> describecluster >> describering >> failuredetector >> gcstats >> getauditlog >> getauthcacheconfig >> getconcurrency >> getendpoints >> getfullquerylog >> getlogginglevels >> getseeds >> info >> listpendinghints >> netstats >> profileload (replacement of toppartition (which should be removed in 5.0, >> actually)) >> proxyhistograms >> rangekeysample >> repair >> repair_admin >> ring >> status >> statusautocompaction >> statusbinary >> statusgossip >> tablehistograms >> toppartitions >> viewbuildstatus >> >> From these, if one asks which ones actually make sense to try to tweak the >> output of, they might be >> >> describecluster >> describering >> info >> listpendinghints >> netstats >> proxyhistograms >> repair_admin (if somebody wants to list stuff in json) >> ring >> status >> tablehistograms >> viewbuildstatus >> >> The point I want to make is that I do not think the problem of changing the >> output is too hot. There is basically like 15 at most commands for which the >> output matter because there is not their CQL equivalent or JSON / YAML >> output. >> >> If we are providing CQL / JSON / YAML for couple years, I do not believe >> that the argument "lets not break it for folks in nodetool" is still >> relevant. CQL output is there from times of 4.0 at least (at least!) and >> YAML / JSON is also not something completely new. It is not like we are >> suddenly forcing people to change their habits, there was enough time to >> update the stuff to CQL / json / yaml etc ... >> >> But really, the question I still don't have an answer for is who is actually >> parsing the output, I think I ping user ML list to probe the situation a >> little bit. >> >> (1) https://gist.github.com/smiklosovic/3f4ea8ccae53ad503af13c53789815be >> (2) https://gist.github.com/smiklosovic/f9a681016c22e2dfe88c883b6881cb7c >> >> ________________________________________ >> From: Josh McKenzie <jmcken...@apache.org <mailto:jmcken...@apache.org>> >> Sent: Saturday, July 8, 2023 14:47 >> To: dev >> Subject: Re: Changing the output of tooling between majors >> >> NetApp Security WARNING: This is an external email. Do not click links or >> open attachments unless you recognize the sender and know the content is >> safe. >> >> >> >> Once there is, we are free to change the default output however we want. >> One thing I always try to keep in mind on discussions like this. A thought >> experiment (with very hand-wavy numbers; try not to get hung up on them): >> >> * Let's say there are 5,000 discrete "users" of C* out there (different >> groups of people using the DB) >> * And assume 5% have written some kind of scripting / automation to parse >> our tooling output (250) >> * And let's assume it'd take 18 developer hours (a few days at 6 hours/day) >> to retool to the new output, validate and test correctness, and then roll it >> out to qa, test, validate, and then to prod, test, validate >> >> You're looking at 250 * 18 hours, 4,500 hours, 112.5 40 hour work weeks (2+ >> years for some poor sod without vacations) worth of work from what seems to >> be a simple change. >> >> Now, that estimate could be off by an order of magnitude either way, but the >> motion of the exercise is valuable, I think. There's a real magnified >> downstream cost to our community when we make changes to APIs and we need to >> weigh that against the cost to the project in terms of maintaining those >> interfaces. >> >> The above mental exercise really strongly applies to the periodic >> discussions where we talk about deprecating JMX support. >> >> Not saying we should or shouldn't change things here for the record, just >> want to call this out for anyone that might not have been thinking about >> things this way. >> >> On Fri, Jul 7, 2023, at 3:23 PM, Brandon Williams wrote: >> On Fri, Jul 7, 2023 at 2:20 PM Miklosovic, Stefan >> <stefan.mikloso...@netapp.com >> <mailto:stefan.mikloso...@netapp.com><mailto:stefan.mikloso...@netapp.com >> <mailto:stefan.mikloso...@netapp.com>>> wrote: >> > >> > Great thanks. That might work. >> > >> > So we do not change the default output unless there is json / yaml >> > equivalent. >> > >> > Once there is, we are free to change the default output however we want. >> >> Yes, exactly. Then we have the best of both worlds: programmatic >> access that isn't flimsy, and a pretty display however we want it.
