Juju 2.9 Beta 1 Release Notes

juju
,
1

The Juju team is proud to release Juju 2.9 Beta!

This is a Beta release for what will become Juju 2.9.0.

Kubernetes improvements

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: platforms, architectures and 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!

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 cs: prefix.

To use the latest CharmHub changes, then enable it with the feature flag before you bootstrap.

export JUJU_DEV_FEATURE_FLAGS=charm-hub

juju find

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

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.

juju download

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

A new /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

The 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.

An example:

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.

An example:

$ juju deploy mysql --constraints="allocate-public-ip=false"

The clouds which (so far) support this feature are:

  • Azure
  • Google
  • Openstack

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.

Azure features

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 root-disk-source constraint.

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.

An example:

$ 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”)
  • vault-user-id

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 resgroup_name/des_name

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

Spaces

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 .

Known Issues:

None.

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

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

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

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)

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.

2 Likes