I am sorry, this is the correct link https://lists.apache.org/thread/72j5qfgbttjcmylhcmfq1ptboh641ns0
________________________________________ From: Miklosovic, Stefan <stefan.mikloso...@netapp.com> Sent: Wednesday, July 12, 2023 0:08 To: user@cassandra.apache.org Subject: Re: Survey about the parsing of the tooling's output 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. Thank you very much for your valuable feedback and insights. There is a thread (1) where we are discussing this as well. We should come up with some decisions, you are welcome to participate / follow the discussion there as well if you wish. (1) https://lists.apache.org/list.html?d...@cassandra.apache.org ________________________________________ From: Andrew Weaver <andrewjwea...@gmail.com> Sent: Monday, July 10, 2023 17:37 To: user@cassandra.apache.org Subject: Re: Survey about the parsing of the tooling's output You don't often get email from andrewjwea...@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> 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. +1 to Bowen Song's feedback for the most part. We have processes that parse output from these nodetool commands: * info * netstats * status * version My opinion is that for anyone running a reasonably sized fleet of Cassandra will have different flavors of automation - some things running on the nodes themselves where nodetool is very handy and some things running outside the cluster where virtual tables accessed via cql are preferred. I propose a rule that within a given major version, additional lines of output are acceptable changes, but changes to the format of existing lines of output are forbidden. I would be inclined to accept JSON or YAML output from nodetool for Ruby/Python/etc scripts, but for bash, the human-readable output is more work-able. On Mon, Jul 10, 2023 at 4:35 AM Miklosovic, Stefan <stefan.mikloso...@netapp.com<mailto:stefan.mikloso...@netapp.com>> wrote: Hi Cassandra users, I am a Cassandra developer and we in Cassandra project would love to know if there are users out there for whom the output of the tooling, like, nodetool, is important when it comes to parsing it. We are elaborating on the consequences when nodetool's output for various commands is changed - we are not completely sure if users are parsing this output in some manner in their custom scripts so us changing the output would break their scripts which are parsing it. Additionally, how big of a problem the output change would be if it was happening only between major Cassandra versions? E.g. 4.0 -> 5.0 or 5.0 -> 6.0 only. In other words, there would be a guarantee that no breaking changes in minor versions would ever occur. Only in majors. Is somebody out there who is relying on the output of some particular nodetool commands (or any command in tools/bin) in production? How often do you rely on the parsing of nodetool's output and how much work it would be for you to rework some minor changes? For example, when the tool output prints "someStatistic: 10" and we would rework it to "Some Statistic: 10". Would you be OK if the output changed but you would have a way how to get e.g. JSON or YAML output instead by some flag on nodetool command so it would be irrelevant what the default output would be? It would be appreciated a lot if you gave us more feedback on this. I understand that not all questions are relatable to everyone. Even you are not relying on the output of the tooling in some custom scripts where you parse it, please tell us so. We are progressively trying to provide CQL way how to query the internal state of Cassandra, via virtual tables, for example. Regards Stefan Miklosovic -- Andrew Weaver
