The Juju team is proud to release Juju 2.9 Beta!
This is a Beta release for what will become Juju 2.9.0.
k8s deployments now support:
- juju ssh
- juju scp
- juju debug-hooks
New Kubernetes operators (beta)
Beta: Kubernetes operators and Charm v2 are in a beta preview and therefore are subject to change.
Juju is bringing the Juju agent closer to Kubernetes workloads with the introduction of Kubernetes operators. This change brings an improved Charm metadata (charm metadata version 2) for both VM-based charms and Kubernetes container based charms.
Charm v2 Metadata
The new charm metadata schema deprecates the old
series key and replaces it with three new keys:
systems. Together these new keys can better express the underlying system the charm is deployed to and gives the charm more control to restrict the underlying system to one that it supports.
Charm with Containers
Charms can also now specify a list of containers to run adjacent to the charm. This is achieved through the introduction of the new
containers key in the charm metadata. Currently this is only supported on Kubernetes in the form of Sidecars within the same Pod.
On Kubernetes, charms run as a sidecar to the workload containers (specified in charm metadata). Charms can then connect to each workload container to control entrypoint start-up, execute commands and manipulate the filesystem. Support in the Operator Framework is a work in progress.
Example v2 Metadata (Kubernetes)
name: my-application platforms: - kubernetes architectures: - amd64 systems: - os: ubuntu channel: 20.04/stable containers: my-container: systems: - resource: my-container-image mounts: - storage: database location: /mnt/database storage: database: type: filesystem resources: my-container-image: type: oci-image
CharmHub is a brand new all shiny charm store. CharmHub is going to be replacing the existing charm store. Don’t worry though, we’ll still keep backwards compatibility with the old charm store, so everything should work, with one exception. Previously if you didn’t specify a scheme (
cs:) for your charm/bundle deployments then it would always hit the existing charm store. That is no longer the case, if you want to target the new CharmHub (either no schema or
ch: can be used) and targeting the existing charm store will require the
To use the latest CharmHub changes, then enable it with the feature flag before you bootstrap.
Juju now has the ability to search the CharmHub store directly from the command line. The fuzzy search will find any potential matches to get the fully qualified charm/bundle name so it makes it a breeze to deploy a charm without leaving the command line.
Juju info displays important and vital information about a given charm/bundle, including the various channels available for deployment. In conjunction with
juju find, the Juju command line is now closer integrated with the store.
With the move to the new CharmHub backend, Juju can now download charms directly from the CharmHub store to your local file system. This should make it easier to customise a charm before deploying or fulfil any potential air-gapped strategies.
juju download wordpress
For more information about the CharmHub feature, refer to this discourse post.
Granular control of expose settings for individual application endpoints
Juju now allows charms to request for a set of port ranges to be opened for a particular (or all) application endpoints. In addition, operators can specify which spaces and/or CIDRs should be allowed to reach the port ranges opened for each individual endpoint (or all application endpoints) when exposing applications.
For more information about this new feature please refer to this discourse post.
Juju leases introspection command
/leases introspection endpoint is available to see things like the current leader, pinned leases etc. Filtering can be done per application or model. As with all introspection endpoints, a function wrapper is available when in an ssh session on the machine, eg
$ juju ssh -m controller 0 $ juju_leases $ juju_leases -m default $ juju_leases appname
OVS bridge support for containerized workloads
Juju can now detect and make use (subject to any specified space constraints) of existing OVS host bridges for both KVM and LXD workloads instead of creating new bridges.
Manual Provider Multi Nic and spaces
When using the manual provider, Juju will now discover multiple network devices and allow them their subnets to be partitioned into spaces. The specific behaviour of subnet discovery for the manual provider is described in the spaces documentation.
Creation of storage pool at bootstrap
bootstrap command supports specifying the creation of a single storage pool in the controller model. This is needed for cases where the storage pool is to be used to configure the provisioning of the controller machine itself (see Azure root disk encryption below). The syntax used is similar to how
--config parameters are specified; key value pairs or config from a file.
juju bootstrap azure \ --no-default-model \ --storage-pool name=encrypted-disk \ --storage-pool type=azure \ --storage-pool encrypted=true \ --storage-pool vault-name-prefix=secret \ --bootstrap-constraints="root-disk-source=encrypted-disk"
Allocate public IP address constraint
There’s a new
allocate-public-ip constraint which allows specifying that machines should not be provisioned with a public IP address (the default is
true). The prime driver for this feature for deploying workloads to public cloud (Azure, Google, AWS, Oracle etc). It also is used in preference to the
use-floating-ip model config on Openstack, which is now deprecated.
$ juju deploy mysql --constraints="allocate-public-ip=false"
The clouds which (so far) support this feature are:
AWS and Oracle will be added soon.
vSphere improvements from 2.8.4
If you’re upgrading from 2.8.3 or earlier, Juju 2.9 includes the vSphere improvements mentioned in the 2.8.4 release notes: notably, the vSphere provider now supports deploying to clusters and hosts inside folders, including any nested combination of sub-folders.
Encrypted root disk with customer managed keys
When provisioning an Azure instance, it is now possible to ask for root disk encryption using a disk encryption set and a key vault. The mechanism to enable this is to set up a Juju storage pool with the necessary configuration and refer to the storage pool using the
You can either BYO an existing disk encryption set or have Juju create a key vault and disk encryption set as part of the machine provisioning. Right now, the key size and algorithm is not user configurable; it’s RSA and 4096 bits.
$ juju create-storage-pool encrypted-disk azure encrypted=true vault-name-prefix=blah $ juju add-machine --constraints="root-disk-source=encrypted-disk"etc $ juju deploy mysql --constraints="root-disk-source=encrypted-disk" etc
The configurable parameters for the storage pool are:
- encrypted (must be true for Juju to act on it)
- vault-name-prefix (the name to give to the key vault)
- disk-encryption-set-name (defaults to vault name prefix)
- vault-key-name (defaults to “disk-secret”)
If just the disk encryption set name is configured, Juju will use that existing disk encryption set and not create any addition resources. It can reside in a different resource group by specifying
If a vault name prefix is also configured, Juju will create a vault called
vault_name_prefix-<UUID>. Vault names need to be unique across a subscription.
If vault-user-id is configured, that user will be given full access to manage the vault and keys created by Juju.
Use existing virtual networks
Juju will normally create a single virtual network
juju-internal-network for each model, and also one subnet with a hard coded CIDR in that virtual network. Sometimes it’s necessary to set up virtual networks and multiple subnets in a way not modelled by Juju. To use an existing virtual network for a model, the
network config can be used. The network will usually be set up in a separate resource group.
$ juju add-model --config network=some_resource_group/some_network`
Any subnets in said network are available to Juju. Subnet placement can be used to bring up a machine on a given subnet, eg
$ juju add-machine --to subnet=some_subnet
The Azure provider now supports spaces, meaning any available subnets are recorded in the Juju model and are available for allocation to named spaces. Said spaces can then be used in constraints.
Multiple NICs per instance
Azure instances are now created with multiple NICs if the space constraints dictate that the instance is to be provisioned with access to more than one subnet.
This release also includes fixes to the following issues:
- LP # 1895963 - cannot upgrade a 2.8 controller with a 2.9 client
- LP # 1893844 - create-backup fails on 2.9-beta1
- LP # 1898816 - juju-restore fails with controller on Focal (with juju-db snap)
Additional bugs fixed can be found on the 2.9 milestone page .
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 --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
Upgrading the Juju client through other channels
To prevent any confusion in later steps, ensure that you’re using the new Juju version.
What to do if Juju reports an old version
The controller state can be saved to allow for recovery in case the upgrade process encounters a serious error.
Juju includes a command that instructs the controller to upgrade itself to the latest version.
How to upgrade the controller
Your models remain at the same version until you have explicitly told Juju to upgrade them.
How to upgrade your model(s)
Juju’s documentation pages provide detailed information about the upgrade process:
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.