The Juju team is proud to release Juju 2.8.0. We aim to be your preferred tool for writing operators, software that manages software, whether your hosting infrastructure is Kubernetes, in the cloud or on-premise.
2.8 Highlights
New Features
Juju 2.8.0 includes extra features for people using Juju as well as those writing charms for Juju.
- OpenStack models now have multi-NIC support
- A new hook family,
*-relation-created, has been introduced to notify charms when a relation is first created (even if a unit is not available on the other side of the relation) - A new hook,
remove, has been added to allow charms to clean up after themselves - Juju will automatically invoke the
starthook for already started units if it detects that the machine they are running on has restarted - When executing
*-relation-departedhooks, the name of the unit that is departing the relation is now exposed via theJUJU_DEPARTING_UNITenvironment variable - A new set of hook tools (
state-set,state-getandstate-delete) allow charms to persist their internal (per-unit) state information as a set of key-value pairs to the controller instead of having to rely to the local file system for this task. Key length is limited to 256 bytes while values are limited to 64k. The controller additionally exposes a new configuration setting (max-charm-state-size, defaults to2M) to limit to the total amount of state data that each unit is allowed to store to the controller - After a hook completes successfully, all required modifications to its state (e.g. open/close ports, add storage, set relation and charm data etc.) are now applied in a single transaction
- The relation
limitattribute specified inside charm metadata is now taken into account by juju when adding relations and upgrading charms (operators can still provide--forcewhen upgrading to bypass the check)
Other changes
- The
juju-restoretool now supports downgrading - The default logging level has increased to INFO. This should make it easier for Juju administrators to focus on important messages and for charmers to use the DEBUG level to make development more productive
- The new sub-commands to improve actions are enabled via a feature flag:
JUJU_FEATURES=actions-v2 - Juju 2.8.0 addresses dozens of bugs. The list is available through the milestone pages on Launchpad via the beta, or release candidates RC 1, RC 2, and RC 3.
More Details
Issues Resolved
This release includes several fixes. Issues triaged as Critical and High are listed here, other issues are available from the milestone’s page.
Known Issues
Juju 2.8.0 contains a small number of known issues that require workarounds to overcome.
- Cross-model relations: when consuming into a 2.7 model an application offer made in a 2.8 model, the 2.7 Juju client must be used due to a macaroon compatibility issue
- Controller upgrades on Kubernetes (K8s) clouds: when upgrading a k8s controller from Juju 2.6 to 2.8 release, you must first upgrade to the 2.7 series.
- Juju Dashboard on K8s clouds: the new dashboard is not immediately enabled when bootstrapping a k8s controller; after bootstrap you need to run
juju update-dashboard.
How do I install Juju?
The best way to get your hands on this release of Juju is to install it as a snap:
sudo snap install juju --channel=stable --classic
Other packages are available for a variety of platforms, including Windows and macOS. Refer to the full Juju installation documentation.
Those subscribed to a snap channel should be automatically upgraded. If you’re using the PPA or Homebrew for macOS, you should see an upgrade available.
How do I upgrade?
Upgrading Juju is a multi-step process:
- upgrade the client (the Juju binary that you interact with on the command-line)
- (recommended) verify that the client upgrade was successful
- (recommended) back up the controller
- upgrade the controller
- upgrade models
Upgrade the client
If you’ve installed Juju via the snap, your Juju will automatically be installed overnight. To force the update, run:
snap refresh juju --channel=stable
Check version
To prevent any confusion in later steps, ensure that you’re using the new Juju version.
juju version
What to do if Juju reports an old version
Check your $PATH environment variable and that you’ve installed the new version correctly.
On Linux and macOS, use the env command to inspect the environment. On MS Windows, use SET.
Backing up
The controller state can be saved to allow for recovery in case the upgrade process encounters a serious error. The juju create-backup command operates within the controller model and will download the controller’s state to the local machine.
juju switch controller
juju create-backup
Upgrading controllers
Juju includes a command that instructs the controller to upgrade itself to the latest version. Because this release is a release candidate, we need to change the “agent stream” to download the new version of the Juju agent.
juju upgrade-controller
How to upgrade the controller
First, check that you’re interacting with the intended controller. The juju models command reports the current controller on the first line.
juju models
To verify what will occur, use the --dry-run option.
juju upgrade-controller --dry-run
When you’re happy, omit the flag:
juju upgrade-controller
Upgrade models
Your models remain at the same version until you have explicitly told Juju to upgrade them.
juju upgrade-model -m <model-name>
How to upgrade your model(s)
Check that you’re operating in the correct model. juju model highlights the current model with an asterisk:
juju models
To verify what will occur, use the --dry-run option.
juju upgrade-juju --dry-run
When you’re happy, omit the flag:
juju upgrade-juju
Further instructions
Juju’s documentation pages provide detailed information about the upgrade process:
Feedback Appreciated!
We encourage everyone to let us know how you’re using Juju. Please ask questions on on Discourse, send us a message to our Twitter account @juju_devops, tweet using the hashtag #juju_devops, and chat with us at #juju on Freenode via IRC or Matrix.