`nats server cluster step-down` `--json` flag has no effect

[wingsofovnia]

Observed behavior

The step-down subcommand registers a --json flag but all output goes through log.Printf and fmt.Println regardless.

$ nats server raft step-down --json --host nats-1 --context s
WARNING: Using placement tags or node name required NATS Server 2.11 or newer

08:40:37 Requesting leader step down of "nats-0" in a 3 peer RAFT group
08:40:38 New leader elected "nats-1"

The flag is registered in server_cluster_command.go:

natscli/cli/server_cluster_command.go

Line 69 in a29b904

sd.Flag("json", "Produce JSON output").Short('j').UnNegatableBoolVar(&c.json)

But metaLeaderStandDownAction never checks c.json.

Expected behavior

Either wire up JSON output (e.g. emit {"previous_leader": "...", "new_leader": "...", "error": "..."}) or remove the dead flag to avoid confusion.

Server and client version

$ nats --version
0.3.1

Host environment

No response

Steps to reproduce

No response

[ripienaar]

I think inherently these are not really suitable to json output as they make a bunch of requests and react on the output etc, it's an interactive process. So only really viable option is to remove the flag.

/cc @johnweldon

[ripienaar]

@wingsofovnia maybe it would help if the --json flag showed the JSON JSZ output of the elected leader? Could maybe do that. I prefer not to invent non standard JSON output in the CLI cos then it becomes a supported format - so better to show the new leader JSZ as that's subject to the server versioning promises.

Would that help?

[wingsofovnia]

@ripienaar thank you for looking into that.

Let me quickly explain my use case. There is a NATS cluster deployed to K8s (as a StatefulSet). When performing rolling updates of StatefulSets, K8s proceeds one by one in reverse order: node nats-5, node nats-4, … down to nats-0.

To avoid unnecessary leader re-elections mid-rollout, I added a pre-upgrade hook that calls step-down --host nats-0, so that the leader is upgraded last. I want the script to fail if there is an actual issue with this process, but nats: error: preferred server "nats-0" is already leader (10005) exits with code 1 even though it isn’t really an error in my use case.

I was hoping to get something like jq '.error.code' when using --json, or similar. So far, I added a quick check to see if a step-down is needed (via nats server request jetstream --leader | jq -r '.data.meta_cluster.leader') to guard the call, but this is prone to races - albeit rare.

I believe the interactive part could go to stderr when using --json, while the json output would go to stdout. I’m not very familiar with how other commands structure their JSON outputs, so I’m not sure how well this fits, but I would appreciate fields like error.code, error.message, new_leader (perhaps as .data.meta_cluster.leader to align with nats server request jetstream --leader?), and prev_leader (optional).

[ripienaar]

I believe we exit zero and one for success / fail that should be enough for use in that scenario right?

If I do invent some kind of custom json here I would have to do it for the entire CLI - quite an undertaking.

So looking for quicker ways to get what you want. Seems to me 0/1 exit + json on success would get you there?