Show controller version in 'juju controllers'

We want to keep "juju controllers" as a command that always succeeds, and returns instantly. It does this by *only* parsing and printing just the local controllers.yaml file and not making any API calls. This is to avoid the situation where a bad or stuck controller can prevent the user from seeing what controllers they have.

A tabular output option was added to juju show-controller. API calls are made to display the level of access the current user has to that controller, as well as the agent version.

$ juju show-controller --format tabular
CONTROLLER MODEL USER ACCESS CLOUD/REGION VERSION
prod admin@local/controller admin@local superuser lxd/localhost 2.0-beta17.1

show-controller also allows multiple controllers to be specified:

$ juju show-controller --format tabular prod test

We can discuss and tweak the decisions made, and the reasoning for them, if the approach taken is not desirable.

Yes, we want the command to be FAST and that means it has to use cached
output.

But no, it is NOT a good decision to have a parameter like '--format
tabular' change the behaviour of the command - it is explicitly a
parameter about FORMAT not about SCOPE, and a change of behaviour that
crosses those lines is bad UX.

In this case, please *cache* the information desired in the normal
output (version etc) in controllers.yaml. It might be out of date, but a
--refresh option might be used to expand SCOPE to get fresher versions etc.

Mark

No, this is not fixed if it has been done as Ian suggested.

I'll explain what's been done; I think it was unclear. The original work enhanced "juju show-controller" to include the extra agent version and user access information. "juju list-controller" was not changed. Because "juju show-controller" lacked a tabular output option, that was added, but the default remains yaml for show-controller as it is for other juju show commands.

Today I have done additional work to enhance list-controllers command. It still only looks at the local yaml files (for performance) to get the data, but there's now infrastructure to ensure this is able to be kept up to date. The agent version and user access is initially set at bootstrap.

$
$ juju bootstrap ian aws
$ juju list-controllers
CONTROLLER MODEL USER ACCESS CLOUD/REGION VERSION
ian* default admin@local superuser+ aws/us-east-1 2.0-beta18.1+

+ these are the last known values, run with --refresh to see the latest information.
$
$

The information is cached. Run *any* juju command like status or whatever also has the side effect of updating the information. Plus, you can also use the refresh option:

$
$ juju list-controllers --refresh
CONTROLLER MODEL USER ACCESS CLOUD/REGION VERSION
ian* default admin@local superuser+ aws/us-east-1 2.0-beta19.1+
$
$

So now both juju list- and show- controller(s) provide the required information. And the list- variant remains a command that runs locally by default, so that a stuck controller doesn't affect its use.

This work will land for beta18 next week.

Thank Ian, this looks tasteful. I think we can drop the tabular output
from show-controller since it's essentially incomplete (doesn't show
keys etc). So show-controller would be rich and yaml-only,
list-controllers is tabular by default and includes this cached info.

Mark