Agreed with Eric’s point here, yes.- Scott On Jul 12, 2023, at 10:48 AM, Eric Evans <eev...@wikimedia.org> wrote:
I agree with Jackson that having a different output format (JSON/YAML) in order to be able to change the default output resolves nothing in practice.
As Jackson said, "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".
This is true. If this approach is adopted, what will happen in practice is that we change the output and we provide a different format and then a user detects this change because his scripts changed. As he has existing solution in place which parses the text from human-readable output, he will try to fix that, he will not suddenly convert all scripting he has to parsing JSON just because we added it. Starting with JSON parsing might be done if he has no scripting in place yet but then we would not cover already existing deployments.
I think this is quite an extreme conclusion to draw. If tooling had stable, structured output formats, and if we documented an expectation that human-readable console output was unstable, then presumably it would be safe to assume that any new scripters would avail themselves of the stable formats, or expect breakage later. I think it's also fair to assume that at least some people would spend the time to convert their scripts, particularly if forced to revisit them (for example, after a breaking change to console output). As someone who manages several large-scale mission-critical Cassandra clusters under constrained resources, this is how I would approach it.
[ ... ]
For that reason, what we could agree on is that we would never change the output for "tier 1" commands and if we ever changed something, it would be STRICT ADDITIONS only. In other words, everything it printed, it would continue to print that for ever. Only new lines could be introduced. We need to do this because Cassandra is evolving over time and we need to keep the output aligned as new functionality appears. But the output would be backward compatible. Plus, we are talking about majors only.
The only reason we would ever changed the output on "tier 1" commands, if is not an addition, is the fix of the typo in the existing output. This would again happened only in majors.
All other output for all other commands might be changed but their output will not need to be strictly additive. This would again happen only between majors.
What is you opinion about this?
To be clear about where I'm coming from: I'm not arguing against you or anyone else making changes like these (in major versions, or otherwise). If —for example— we had console output that was incorrect, incomplete, or obviously misleading, I'd absolutely want to see that fixed, script breakage be damned. All I want is for folks to recognize the problems this sort of thing can create, and show a bit of empathy before submitting a change. For operators on the receiving end, it can be really frustrating, especially when there is no normative change (i.e. it's in service of aesthetics).
Staff SRE, Data Persistence
Wikimedia Foundation
|
