On a 2.6.2 controller upgraded from 2.5.7, juju upgrade-model makes the following bogus recommendation for a 2.5.7 k8s (microk8s 1.14.1) model:
[agnew(~)] juju upgrade-model -m test --dry-run
best version:
2.6.3
upgrade to this version by running
juju upgrade-model
[agnew(~)] juju upgrade-model -m test
best version:
2.6.3
ERROR model cannot be upgraded to 2.6.3 while the controller is 2.6.2: upgrade 'controller' model first
[agnew(~)] _
This seems to be because there is a 2.6.3 operator image published, despite Juju 2.6.3 itself not being released yet:
[agnew(~)] juju upgrade-model --debug -m test --dry-run
11:25:22 INFO juju.cmd supercommand.go:57 running juju [2.6.2 gc go1.10.4]
11:25:22 DEBUG juju.cmd supercommand.go:58 args: []string{"juju", "upgrade-model", "--debug", "-m", "test", "--dry-run"}
11:25:22 INFO juju.juju api.go:67 connecting to API addresses: [10.9.8.199:17070]
11:25:22 DEBUG juju.api apiclient.go:1092 successfully dialed "wss://10.9.8.199:17070/model/0d2efdac-991a-46d1-89d8-1ce5d0474fb2/api"
11:25:22 INFO juju.api apiclient.go:624 connection established to "wss://10.9.8.199:17070/model/0d2efdac-991a-46d1-89d8-1ce5d0474fb2/api"
11:25:22 INFO juju.juju api.go:67 connecting to API addresses: [10.9.8.199:17070]
11:25:22 DEBUG juju.api apiclient.go:1092 successfully dialed "wss://10.9.8.199:17070/model/0d2efdac-991a-46d1-89d8-1ce5d0474fb2/api"
11:25:22 INFO juju.api apiclient.go:624 connection established to "wss://10.9.8.199:17070/model/0d2efdac-991a-46d1-89d8-1ce5d0474fb2/api"
11:25:22 INFO juju.juju api.go:67 connecting to API addresses: [10.9.8.199:17070]
11:25:22 DEBUG juju.api apiclient.go:1092 successfully dialed "wss://10.9.8.199:17070/api"
11:25:22 INFO juju.api apiclient.go:624 connection established to "wss://10.9.8.199:17070/api"
11:25:22 DEBUG juju.cmd.juju.commands upgradecontroller.go:232 searching for agent images with major: 2
11:25:22 DEBUG juju.docker docker.go:40 operater image tags URL: https://registry.hub.docker.com/v1/repositories/jujusolutions/jujud-operator/tags
11:25:23 DEBUG juju.cmd.juju.commands upgradecontroller.go:238 found available tags: [{{2 5 3 0}} {{2 5 4 0}} {{2 5 5 0}} {{2 5 6 0}} {{2 5 7 0}} {{2 5 8 0}} {{2 6 beta 1 0}} {{2 6 beta 2 0}} {{2 6 rc 1 0}} {{2 6 rc 2 0}} {{2 6 rc 3 0}} {{2 6 0 0}} {{2 6 1 0}} {{2 6 2 0}} {{2 6 3 0}} {{2 7 beta 1 0}}]
11:25:23 DEBUG juju.cmd.juju.commands upgradecontroller.go:248 found matching tags: [{{2 5 3 0}} {{2 5 4 0}} {{2 5 5 0}} {{2 5 6 0}} {{2 5 7 0}} {{2 5 8 0}} {{2 6 beta 1 0}} {{2 6 beta 2 0}} {{2 6 rc 1 0}} {{2 6 rc 2 0}} {{2 6 rc 3 0}} {{2 6 0 0}} {{2 6 1 0}} {{2 6 2 0}} {{2 6 3 0}} {{2 7 beta 1 0}}]
11:25:23 DEBUG juju.cmd.juju.commands upgrademodel.go:785 found a more recent stable version 2.6.3
11:25:23 INFO cmd upgrademodel.go:436 available agent images:
2.5.3
2.5.4
2.5.5
2.5.6
2.5.7
2.5.8
2.6-beta1
2.6-beta2
2.6-rc1
2.6-rc2
2.6-rc3
2.6.0
2.6.1
2.6.2
2.6.3
2.7-beta1
best version:
2.6.3
upgrade to this version by running
juju upgrade-model
11:25:23 DEBUG juju.api monitor.go:35 RPC connection died
11:25:23 DEBUG juju.api monitor.go:35 RPC connection died
11:25:23 DEBUG juju.api monitor.go:35 RPC connection died
11:25:23 INFO cmd supercommand.go:502 command finished
This isn't a k8s issue.
The issue is that for Juju in general, you cannot upgrade a model to a version of Juju that is newer than the controller hosting the model. The workflow needs to be:
- upgrade controller first
- then upgrade any models hosted on that controller
The --dry-run message should also check the controller version before making a recommendation so that the message to the user can be improved.