We parse the output of the following nodetool sub-commands in our custom
scripts:
* status
* netstats
* tpstats
* ring
We don't mind the output format change between major releases as long as
all the following are true:
1. major releases are not too frequent
e.g. no more frequent than once every couple of years
2. the changes are clearly documented in the CHANGES.txt and mentioned
in the NEWS.txt
e.g. clearly specify that "someStatistic:" in "nodetool somecommand"
is renamed to "Some Statistic:"
3. the functionality is not lost
e.g. remove a value from the output with no obvious alternative
4. it doesn't become a lot harder to parse
e.g. split a value into multiple values with different units, and
the new values need to be added up together to get the original one
We have Ansible palybooks, shell scripts, Python scripts, etc. parsing
the output, and to my best knowledge, all of them are trivial to rework
for minor cosmetic changes like the one given in the example.
Parsing JSON or YAML in vanilla POSIX shell (i.e. without tools such as
jq installed) can be much harder, we would rather not to have to deal
with that. For Ansible and Python script, it's a nonissue, but given the
fact that we are already parsing the default output and it works fine,
we are unlikely to change them to use JSON or YAML instead, unless the
pain of dealing with breaking changes is too much and too often.
Querying via CQL is harder, and we would rather not to do that for the
reasons below:
* it requires Cassandra credentials, instead the credential-less
nodetool command on localhost
* for shell scripts, the cqlsh command output is harder to parse than
the nodetool command, because its output is a human-friendly table
with header, dynamic indentations, field separators, etc., which
makes it a less attractive candidate than the nodetool
* for Ansible and Python scripts, using the CQL interface will require
extra modules/libraries. The extra installation steps required make
the scripts themselves less portable between different
servers/environment, so we may still prefer the more portable
nodetool approach where the localhost access is possible
On 10/07/2023 10:35, Miklosovic, Stefan 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
