I have run into some confusing behaviour using the `juju upgrade-controller' command.
After updating my local client version to 2.8-beta1 from the "edge" channel via snap, I wanted to do the same on the controller. Here are the commands I ran: https://paste.ubuntu.com/p/C3dkpn2dFW/
There are two things that I found confusing in that output.
One is that, when calling `upgrade-controller --dry-run', the user is shown a candidate version and told that they can upgrade to that version by running `juju upgrade-controller' (without any arguments). However, that won't actually do what the user wants if they have passed `--agent-version' or `--agent-stream' flags. I think the command that's suggested should probably include any flags the user has provided (apart from `--dry-run' of course) to make sure the command they're told to run will actually do what they want.
The second is that I when eventually ran the command without `--dry-run' it installed a different version than the one that was specified. I asked for agent-version 2.7.2 and agent-stream "released" (at this point I was just troubleshooting), but I got 2.8-beta1 like I had been trying to install earlier, despite the command line flags.
Let me know if I can provide any other info, thanks!
I think we can make some UX improvements here.
There's also a distinct different is what's possible with cloud vs k8s. I assume you're talking about k8s? There error messages below seem tailored to cloud and should be reworked to take account of the fact that k8s needs docker images available. With cloud, you can just use an arbitrary agent binary directly.
The comments below pertain to cloud rather than k8s as I think there's also improvements there as well.
<snip>
$ juju upgrade-controller --dry-run --agent-
no prepackaged agent binaries available, using local agent binary 2.8.0.1
best version:
2.8.0.1
upgrade to this version by running
juju upgrade-controller
<snip>
Because there's no official Juju 2.8.0 binary in devel stream, it is saying that it will need to compile a copy from source (or finad a locally compiled binary) and upload that. The .1 at the end of the X.Y.Z version is the build number and signifies an unofficial build.
<snip>
$ juju upgrade-controller --dry-run --agent-
no prepackaged agent binaries available, using local agent binary 2.8.0.2
best version:
2.8.0.2
upgrade to this version by running
juju upgrade-controller
<snip>
Doing the above is not really kosher as providing an unofficial version to --agent-version doesn't really make sense. Juju should error here. It's adding 1 to the build number of the version it cannot find and is saying it will compile a local version.
<snip>
$ juju upgrade-controller --dry-run --agent-
no prepackaged agent binaries available, using local agent binary 2.8.0.3
best version:
2.8.0.3
upgrade to this version by running
juju upgrade-controller
<snip>
Ditto.
<snip>
$ juju upgrade-controller
no upgrades available
<snip>
There are no released versions in the stable stream past 2.7.1.
<snip>
$ juju upgrade-controller --dry-run --agent-
no prepackaged agent binaries available, using local agent binary 2.7.2.1
best version:
2.7.2.1
upgrade to this version by running
juju upgrade-controller
<snip>
No released 2.7.2 version hence local compiled version would be used.