Juju 2.5.0 Beta 3 Release Notes


#1

Call for testing! Juju 2.5 beta3

The Juju team is preparing for their latest major release of Juju, 2.5. We’ve put together an array of new features and improvements that we’re eager for everyone to test, provide feedback, and get ready to use! With the release of Beta 1 the Juju team stands behind upgrading any running Juju infrastructure through the Beta releases, the RC releases, and into a final GA version available in the coming weeks. Please kick the tires and let us know what you think!

Note: beta 2 has been deliberately skipped. There was a build issue during
the release process and we had to burn that release number.

Juju 2.5 beta3 changes

AWS Instance Types

New AWS instance types release in November are now available for use with juju.

New config-changed hook behaviour

The config-changed hook is now only run when needed. This solves a problem on deployments with a large number of units whereby the system thrashed after any upgrade (or other agent restart) due to each and every unit agent running config-changed for all charms. Instead of speculatively running the hook whenever the agent restarts, or when an update is made that doesn’t really change anything, we now track the hash of 3 artefacts - config settings, machine/container addresses, trust config. If any of these change, the hook is run. The agent still checks on start up but will no longer run the hook if nothing has changed since the last invocation.
Note, the first agent restart after upgrade to Juju 2.5 will run the hook as there are no hashes recorded yet.

This release includes more important fixes

  • LP #1804701 - (2.5-beta1) juju upgrade-series from Trusty to Xenial hangs up
  • LP #1787753 - Add europe-north1 region to google clouds
  • LP #1778033 - juju stuck attaching storage to OSD
  • LP #1751858 - support vsphere disk.enableUUID model config

Additional bugs fixed can be found in the milestone page.

Juju 2.5 beta1 changes

Kubernetes Workloads

Juju now supports deploying Kubernetes workloads. Reading the linked posts below top to bottom is a good way to get started. Note that while we’re still in Beta the charmstore is still getting updated to host Kubernetes based charms. Testing of this feature requires using the staging charmstore for now. This is noted in the various instructions and how-tos linked below.

Getting Started
A Basic Kubernetes Demo
Using Microk8s
Cloud and Credential Management
Advanced Configuration
Storage Support
Advanced Storage Support
Operator Storage
Scale Application Command
Bundles
Writing a Kubernetes Charm
Preliminary Support for GKE

LXD clustering support

Juju now supports managing models on a remote LXD cluster. Leveraging the density of a LXD cluster of remote machines means you can test full HA scenarios in complex workloads easily. With three bare metal machines you can create a HA Juju control plane along with deploying HA enabled workloads. This is a great setup for development, testing, and QA’ing failover scenarios or just providing a great dense “micro cloud” for a team to work against.

Documentation available: https://docs.jujucharms.com/devel/en/clouds-lxd-advanced#lxd-clustering
Tips on setting up the LXD cluster networking: Manual Network Setup for LXD Clustering

Upgrading of underlying OS support

Juju supports a new upgrade-series command that allows you to upgrade a machine running Ubuntu Trusty to Xenial or Xenial to Bionic. Charms now have the ability to provide new hooks that can script the work required for applications to handle the big OS upgrade scenario. With this you can now migrate your infrastructure without redeploying and keep up with the latest LTS releases available.

Documentation available: https://docs.jujucharms.com/devel/en/upgrade-series

The OpenStack charms are updated to support this in their latest release. You can see updated upgrade documentation using this feature here: https://docs.openstack.org/project-deploy-guide/charm-deployment-guide/latest/app-series-upgrade.html

Bundle Export Feature

This feature provides a CLI command which exports the configuration of the current model in bundle format which can then be used for subsequent (re-)deployment.

The command added to support this functionality is ‘export-bundle’.
Usage:

    juju export-bundle --filename <outputfile>
    juju export-bundle

If --filename option is not specified the output is printed to STDOUT.

Bundle Diff Feature

This feature provides a command to compare a bundle with a model and report any differences. This is really useful when you’re trying to see what changes might have been made in production over time that are different than the original bundle you started out with. You might also use this to snapshot updates to the bundle over time.

Usage:

    juju diff-bundle [options] <bundle file or name>

The bundle to compare can be a local bundle file or the name of a bundle in the charm store. The bundle can also be combined with overlays (in the same way as the deploy command) before comparing with the model.

The map-machines option works similarly as for the deploy command, but existing is always assumed, so it doesn’t need to be specified.

Here are some examples to demonstrate the flexibility available:

    juju diff-bundle localbundle.yaml
    juju diff-bundle canonical-kubernetes
    juju diff-bundle -m othermodel hadoop-spark
    juju diff-bundle mongodb-cluster --channel beta
    juju diff-bundle canonical-kubernetes --overlay local-config.yaml --overlay extra.yaml
    juju diff-bundle localbundle.yaml --map-machines 3=4

More notes here: New diff-bundle command

Charm provided LXD profiles

Sometimes an application needs to have a LXD profile with some tweaks in order to work properly in a LXD container. Some examples of this include things like allowing nested containers, so that workload creating Docker containers is able to create those containers, or perhaps an application needs a kernel module added into the LXD container it runs in. In Juju 2.5 charms can now provide a lxd-profile.yaml file that helps tell Juju what it needs. Juju will then make sure that the LXD containers the application runs it is provided the tweaks it needs.

Documentation available: https://docs.jujucharms.com/devel/en/clouds-lxd-advanced#charms-and-lxd-profiles
A charm in development using this feature can be seen here (note the lxd-profile.yaml in the file listing): https://jujucharms.com/u/openstack-charmers-next/neutron-openvswitch/

Oracle Cloud Infrastructure Support

Juju now supports Oracle Cloud Infrastructure (OCI) as a cloud.

The cloud is called “oci” and is not to be confused with the existing “oracle” provider. Oracle now refers to this cloud as “OCI Classic” and it is in line for deprecation from Juju.

Instructions on getting started with OCI as a Juju cloud can be found here.

Credential Management and Validation

Juju uses a cloud credential to bootstrap a controller or to add a model. This credential is then used in cloud communications on the model’s behalf. The credentials however can expire, be revoked and deleted or simply need to be changed during the life of the model. From 2.5, Juju gains the ability to react to these changes.

Whenever the underlying cloud rejects Juju’s call because of an invalid credential, all communications between this model and the cloud are stopped until the credential is either updated or changed. If more than one model uses the same credential, these models will react the same way. This ability has been rolled out to most supported cloud providers.

In order to re-enable cloud communications on the models that have invalid credentials, users can use an existing ‘update-credential’ command. If the model requires a completely different credential, a new command has been created to allow users to upload a new credential and use it on the model, see ‘set-credential’.

Juju users can examine what credential models have via ‘show-model’ or ‘show-credential’ commands.
More details and use cases on the topic will be coming to Discourse.

OpenStack cloud config supports CA_CERT

Juju now supports OpenStack clouds requiring CA Certificates. Simply run juju add-cloud with your novarc file sourced, juju will pick up the value of OS_CACERT, or provide the location of the certificate and juju will take it from there.

OpenStack cloud config supports CA Cert

This release includes more important fixes

  • LP #1787986 - Run action on leader
  • LP #1799365 - Juju HA controllers need to distribute client connections
  • LP #1796378 - Subordinate charm deployment ignores global series settings
  • LP #1776995 - subordinate can’t relate to applications with different series

Additional bugs fixed can be found in the milestone page.

How do I get it?

The best way to get your hands on this release of Juju is to install it as a
snap package

sudo snap install juju --classic --beta

Other packages are available for a variety of platforms. Please see the online
documentation at https://jujucharms.com/docs/stable/reference-install. Those
subscribed to a snap channel should be automatically upgraded. If you’re using
the ppa or homebrew, you should see an upgrade available.

Feedback Appreciated!

We encourage everyone to let us know how you’re using Juju. Join us on Discourse at https://discourse.jujucharms.com/, send us a message on Twitter using the hashtag #jujucharms, and join us at #juju on freenode.


#2

@manadart FYI instance types have been updated for the Oracle Compute Infrastructure (OCI) provider. Updates include bare metal instances with GPUs and more larger VM types.