This is an addendum to the main page describing Juju software upgrades: Model upgrades.
In general, the upgrade of the agent software is independent of the following:
Although client and server software are independent, an upgrade of the agents is an opportune time to first upgrade the client software.
Charms and agent versions are orthogonal to one another. There is no necessity to upgrade charms before or after an upgrade of the agents.
Workloads running are independent of Juju so a downtime maintenance window is not normally required in order to perform an upgrade.
A version is denoted by:
When not specifying a version to upgrade to ('--version') an algorithm will be used to auto-select a version.
If the agent major version matches the client major version, the version selected is minor+1. If such a minor version is not available then the next patch version is chosen.
If the agent major version does not match the client major version, the version selected is that of the client version.
To demonstrate, let the available online versions be: 1.25.1, 2.02, 2.03, 2.1, and 2.2. This gives:
- client 2.03, agent 2.01 -> upgrade to 2.02
- client 1.25, agent 1.25 -> upgrade to 1.25.1
- client 2.1, agent 1.25 -> upgrade to 2.1
The stable online agent software is found here: https://streams.canonical.com/juju/tools/releases/
This pertains to the lack of internet connectivity for the controller.
If the controller cannot contact the above URL then the client, which
presumably does have access, will need to download and transfer the software
to the controller prior to requesting an upgrade. This is accomplished with
Transfer the server software (auto-selected) to the state server:
Transfer the specified server software (all patch versions of 2.03) to the state server:
juju sync-agent-binaries --version 2.03 --debug
sync-agent-binaries --version command only accepts
major[.minor] ("e.g. use '2.03' not '2.03.1').
For complete syntax, see the
command reference page or by running
juju help sync-agent-binaries.