I am +1 (nb) on the proposal to change the human readable output in a major release as long as we have a machine readable output that can be consumed by scripts.
On 2023/07/10 23:06:11 "Fleming, Jackson" wrote: > We use Nodetool in scripts sparsely, in my opinion trying to programmatically > parse the human readable output should be avoided as much as possible, it’s > usually leads to implementations that are brittle. > > I certainly agree you don’t want to make these kinds of changes in 3.11 or > 4.x (and I don’t think that’s what Stefan was suggesting), but I don’t > necessarily agree that you can’t make these kinds of changes in major > versions. Chasing compatibility like this seems like a deep rabbit hole one > could possibly go down, I personally don’t see it as unreasonable for > commands that are designed to be read by humans to be updated over time to > improve readability, as that is the purpose of those commands. While people > script against that output I don’t think anyone is going to say it’s an > official API, the project also makes no public commitment to that either. > > If the proposal is to treat Nodetool input and output like a contract/API, > it’d be great for a formal specification, or at least the documentation to be > updated to cover what users should expect as output from Nodetool, if the > project is going to such effort to maintain a specification, why not make it > official? That way the maintainers of scripts have a fighting chance of > finding incompatibilities before upgrading their infrastructure and the > project could make these kinds of changes and provide a mechanism for users > to validate. > > Currently the argument could be made that there’s no guarantee about Nodetool > output since it’s not actually written down anywhere official outside the > codebase. > > Isn’t this one of the reasons Cassandra maintains the NEWS and CHANGES files > in the repo, and follows semantic versioning, to communicate potentially > breaking changes as clearly as possible? Surely a message like (but with some > more detail) “Nodetool command x has had its human readable output > restructured, item y was removed/renamed to z” would suffice. > > Not sure if you can deprecate the human readable output without generating a > lot of noise for the user, and if it’s being parsed by a bash script, the > user would never see it anyway, but sounds like that’s what the project needs. > > To the note about having users migrate over to more machine friendly output > types (JSON etc), in my experience the operators who maintain these scripts > aren’t going to re-write them just because a better way of doing them is > newly available, usually they’re too busy with other work and will keep using > those old scripts until they stop working, so in my view it’s not really a > solution to this problem. > > Regards, > > Jackson > > From: Eric Evans <john.eric.ev...@gmail.com> > Date: Tuesday, 11 July 2023 at 4:14 am > To: dev@cassandra.apache.org <dev@cassandra.apache.org> > Subject: Re: Changing the output of tooling between majors > You don't often get email from john.eric.ev...@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. > > > > > On Sun, Jul 9, 2023 at 9:10 PM Dinesh Joshi > <djo...@apache.org<mailto:djo...@apache.org>> wrote: > On Jul 8, 2023, at 8:43 AM, Miklosovic, Stefan > <stefan.mikloso...@netapp.com<mailto:stefan.mikloso...@netapp.com>> wrote: > > 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 ... > > What % of Cassandra users are using 4.0+? Operators who upgrade to 4.0 and > beyond may still use their existing scripts. Therefore keeping things stable > is important. Until nodetool can support JSON as output format for all > interaction and there is a significant adoption in the user community, I > would strongly advise against making breaking changes to the CLI output. > > +1 > > -- > Eric Evans > john.eric.ev...@gmail.com<mailto:john.eric.ev...@gmail.com> >
