You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge pull request juju#11384 from babbageclunk/2.8-downgrade-agent
juju#11384
## Description of change
Previously the upgrader rejected a version change if the target minor or major version was less than the current version. This check has been removed to support rolling back the Juju version by restoring a backup taken before an upgrade.
The same change has been made in the caasupgrader worker - the upgrade process is different in k8s land but this check was essentially the same.
With these changes restoring a previous version of a controller automatically triggers the agents to download the required version of the agent, symlink it and update the upgradedToVersion in the agent.conf.
There was a mention of a bug in upgrading from 1.16 to 1.18: https://bugs.launchpad.net/juju-core/+bug/1299802
My understanding is that this behaviour isn't a concern any more because the unit agent no longer considers the machine agent's version; everything is driven by the model agent version instead.
## QA steps
* Bootstrap with Juju 2.7.
* Deploy some units.
* Take a backup of the controller.
```sh
juju create-backup -m controller
```
* Upgrade to 2.8 with this change, and upgrade the model as well.
```sh
juju upgrade-controller --build-agent
juju upgrade-model
```
* Run juju-restore on the controller machine. At the moment this requires a version of juju-restore hacked to remove the check requiring the same version between controller and backup.
```sh
juju scp -m controller $(which juju-restore) 0:
juju scp -m controller juju-backup-whenever-it-is.tar.gz
juju ssh -m controller 0
# On machine
sudo grep statepassword /var/lib/juju/agents/machine-0/agent.conf
./juju-restore --username machine-0 --password thepassword --verbose juju-backup-whenever.tar.gz
```
* After restore the controller agent will start complaining about downgrading state from 2.8 to 2.7.4 - this is unnecessary because the db is already at 2.7.4, it's just because the agent.conf is wrong. Stop the agent and edit agent.conf to set upgradedToVersion back to 2.7.4:
```sh
$ sudo systemctl stop jujud-machine-0.service
$ sudo vi /var/lib/juju/agents/machine-0/agent.conf
$ sudo systemctl start jujud-machine-0.service
```
(Once the version downgrade changes are made to juju-restore this will happen automatically.)
* The unit and machine agents in the model will update their symlinks to point to the 2.7.4 binary and their agent.confs with the correct upgradedToVersion.
* Their log files will show that the right version of the binary is running.
## Documentation changes
No change to documentation.
## Bug reference
None
0 commit comments