Juju 2.8-rc1 Release Notes

[wallyworld (Ian Booth)]

The Juju team is proud to release Juju 2.8-rc1! This release contains a number of fixes for issues in the previous beta1 release, for which we welcome testing. We recommend that administrators of production systems wait until 2.8.0 is finally. See “How to test” below.

Getting started

Because this is an RC, be sure to bootstrap with --agent-stream=proposed in order for Juju to find the agent binaries to run.

juju bootstrap --config agent-stream=proposed ,,,

New in RC1

Legacy lease option is removed

The legacy-lease feature flag is no longer supported - all leases are managed by raft.

Easier centos and windows image selection

Easier centos and windows image selection

Juju 2.8 will make it much easier to configure Juju to use centos and windows images on clouds like AWS or Openstack which use simplstreams metadata to catalog the available images. This feature will be in 2.8-rc1 or the 2.8-rc1+develop-8c74d2a53a edge snap before that. Quick Intro There’s 3 basic commands: juju metadata add-image juju metadata delete-image juju metadata list-images In its simplest form, add-image is used to register an image id for a specified series. Other attributes from s…

New AWS Regions

• af-south-1 (Cape Town)
• eu-south-1 (Milan)

OpenStack Nova networking not supported in juju 2.8 and beyond.

Bootstrap and upgrade of an OpenStack using Nova networking is no longer supported and will not be allowed by those commands.

Please use Neutron networking in OpenStack clouds.

Significant Issues Resolved

As well as the new features highlighted above, this release includes fixes to the following issues:

• LP #1877065 - juju reboot stopped working
• LP #1877228 - k8s operator charm can’t run actions/juju run
• LP #1876345 - destroy-model --force cleans up stuck storage
• LP #1874031 - vSphere root-disk-source datasources can be nested inside a folder
• LP #1859121 - kvm based units are ignoring container-image-metadata-url

The full listing can be found in the milestone page. Look for issues classified as “Fix Released”.

Known issues

• 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
• when upgrading a k8s controller to this 2.8 release, you must first upgrade to 2.7
• sometimes the deployment of a k8s charm fails due to a report 137 error; restart the application operator pod manually and it should come good (will be fixed before 2.8.0)

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 start hook for already started units if it detects that the machine they are running on has restarted
• When executing *-relation-departed hooks, the name of the unit that is departing the relation is now exposed via the JUJU_DEPARTING_UNIT environment variable
• A new set of hook tools (state-set, state-get and state-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 to 2M) 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 limit attribute specified inside charm metadata is now taken into account by juju when adding relations and upgrading charms (operators can still provide --force when upgrading to bypass the check)

Other changes

• The juju-restore tool now supports downgrading
• Hook execution order has changed
• 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 their

More Details

What's new in Juju 2.8

The Juju 2.8 series brings several features to the Juju community. Usability enhancements Improved resource usage Juju agents (jujud processes) now use less memory, particularly for long-lived models. Increased speed Several internal changes have led to speed improvements while executing hooks. This means that all Juju operations should run faster on Juju 2.8 than previous versions.

Further details

As an implementation detail, the Juju controller stores its state within a database. Research …

How do I help with testing?

A minor Juju release goes through three phases:

• release candidate (this release)
• final (expected before 15 May)

Testing is recommended on new controller. Using a newly installed Juju client (see “How do I install Juju?” below), run the juju bootstrap command.

Once the bootstrap process has been completed, attempt to deploy your standard workloads. Juju should function as expected.

Testing Actions

The new Actions sub-commands are enabled via a feature flag.

JUJU_FEATURES=actions-v2 juju 

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=2.8/candidate --classic

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=candidate

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.

juju create-backup

Upgrading controllers

Juju includes a command that instructs the controller to upgrade itself to the latest version.

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

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:

• Controller backups
• Upgrading models
• Notes on upgrading Juju software
• Troubleshooting model upgrades

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.