On Wed, Jul 12, 2023 at 1:54 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> 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.

TL;DR Don't let perfect by the enemy of good
<https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good>

[ ... ]
>


> 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).

-- 
Eric Evans <eev...@wikimedia.org>
Staff SRE, Data Persistence
Wikimedia Foundation

Reply via email to