Specific controller endpoints should be able to be targeted when running juju commands

[Connor Chamberlain]

When checking the health of juju controllers, it is common to repeated run juju commands with the --debug flag to see which API endpoint is consuming your commands. Operators often do this as a verification step on all three controllers after performing maintenance. However, because we cannot target the specific controller(s) we are interested in, we have to spam something like `juju status --debug` several times and examine how those commands hit each of the controllers. This becomes something like a probabilistic distribution. It would be far more convenient to be able to do something like `juju status --debug --endpoint=<ip>`.

[Ian Booth (wallyworld)]

You can tell any juju command to operate on a specified controller and model, typically using the -m option.

eg

juju status -m mycontroller:mymodel

or just

juju status -m mymodel

(see juju help status)

You can also set JUJU_CONTROLLER and JUJU_MODEL env vars as well, so that -m is not needed.

So I am confused by the statement that "we cannot target the specific controller(s) we are interested in". Is there something else you are trying to do that I am not understanding?

[Connor Chamberlain (lcvcode)]

Hi, yes we can use the `juju status -m <controller>:<model>` to have a specific juju controller (as shown in `juju controllers`) execute the command, but that is not every helpful. Controllers are often setup in an HA configuration, resulting in them having multiple API endpoints. Operators care about testing each of these endpoints to determine if the controller as a whole is functioning as expected.

Here is what I mean:
$ juju status --debug | head
INFO juju.cmd supercommand.go:56 running juju [2.9.42 7b871e782195bdac9c90f8a8f01723cc3e08ab92 gc go1.18.10]
DEBUG juju.cmd supercommand.go:57 args: []string{"/snap/juju/22345/bin/juju", "status", "--debug"}
INFO juju.juju api.go:86 connecting to API addresses: [<address-1>:<port> <address-2>:<port> <address-3>:<port>]
DEBUG juju.api apiclient.go:1152 successfully dialed "wss://<address-1>:<port>/model/<uuid>/api"
INFO juju.api apiclient.go:687 connection established to "wss://<address-1>:<port>/model/<uuid>/api"
<normal juju status output>

Operators have to repeat this process many times to see if all three API addresses are consuming juju commands at a relatively homogeneous rate. It would be far more useful to be able to target specific endpoints.

I modified the name of this bug and the description to better reflect this clarification.

[Ian Booth (wallyworld)]

Oh I see. Thanks for the clarification. Internally, we tend to think of "controller" as a named HA set, ie what you see when you run "juju controllers" or "juju show-controller".

juju show-controller does help a bit. eg if the agent for controller 2 is down, you see this

  controller-machines:
    "0":
      instance-id: i-05b5a0fb8f4ad33ca
      ha-status: ha-enabled
      ha-primary: true
    "1":
      instance-id: i-06a3438166d083afa
      ha-status: ha-enabled
    "2":
      instance-id: i-02fb8ce57981c328f
      ha-status: ha-pending

So that may be of use - it effectively gives the same info as opening an api connection pass/fail.