A Juju client mismatch should be handled gracefully

[Peter Matulis]

The machine preparation step (prepare-node-script) will install the correct Juju snap if the snap is not present. However, if the snap is present but is of the incorrect (incompatible) version then the bootstrap command will fail unceremoniously.

At the preparation step, we should detect the problem that is guaranteed to occur and at least warn the user that they need to take some action (i.e. juju refresh).

If the user proceeds anyway, the bootstrap command should fail early with a similar message and avoid a stacktrace from being displayed.

$ juju version
3.1.5-genericlinux-amd64

$ sudo snap install openstack --channel 2023.1
$ sunbeam prepare-node-script | bash -x && newgrp snap_daemon

$ sunbeam cluster bootstrap --accept-defaults
Error bootstrapping Juju
Traceback (most recent call last):
  File
"/snap/openstack/247/lib/python3.10/site-packages/sunbeam/commands/juju
.py", line 290, in run
    process = subprocess.run(cmd, capture_output=True, text=True,
check=True)
  File "/usr/lib/python3.10/subprocess.py", line 526, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command
'['/snap/openstack/247/juju/bin/juju', 'bootstrap', 'sunbeam',
'sunbeam-controller', '--agent-version=3.2.0']' returned non-zero exit
status 2.
ERROR this client can only bootstrap 3.1 agents

Error: Command '['/snap/openstack/247/juju/bin/juju', 'bootstrap', 'sunbeam', 'sunbeam-controller', '--agent-version=3.2.0']' returned non-zero exit status 2

[James Page (james-page)]

We are due to remove the agent version from the codebase which means that the version of juju installed will be the version used throughout - this enables some interesting possibilities for placement of sunbeam in the test gates of the Juju project.

2023.1/stable,candidate still have this pin.