Juju 2.9.3 Release Notes

The Juju team is proud to release Juju 2.9.3. 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-premises.

This release includes these new features:

  • Sidecar charms: Pebble now forwards stdout and stderr from services to Pebble’s own stdout, allowing you to more easily debug an application’s output with kubectl logs and similar tools. See Juju PR 13004 for example output. This is a preview feature – the exact format may change in future patch releases.
  • Sidecar charms: using Pebble, you can now start services with a non-root user or group by adding user and group to the service configuration in your Pebble layer.

And the following bug fixes

LP #1920820 - juju dashboard returns immediately and fails to open port with microk8s controller
LP #1927135 - Model default series is not honoured - wrong series gets deployed
LP #1928286 - bash completion complaints python2 is required
LP #1929100 - panic when attempting to prepare release-upgrade from Xenial to Bionic

Additional bugs fixed can be found in the milestone page.

Known Issues

Upgrading an older k8s model is broken

Upgrading a k8s model to this release is broken. The controller can be upgraded without a problem using juju upgrade-controller, however using juju upgrade-model to upgrade an older 2.8 or 2.9 model is broken. This issue is already fixed for the next 2.9.4 release.

Upgrade Notes

libjuju Python Upgrade Steps

Juju is about to release a new version of our Python library to support the new Kubernetes proxy mechanism added in 2.9.0. This allows users to bootstrap to Kubernetes clusters that may not have a native means of exposing the Juju controller to clients.

To facilitate this Juju proxy’s through the Kubernetes api to talk with the controller. To allow these changes in Juju to work in the Python library a small RBAC change has to be made in Kubernetes if you are upgrading a controller from 2.9.0 to 2.9.2. This step does not have to be done for any other case.

  1. Firstly identify the name of the controller namespace in kubernetes. This can be done running kubectl get ns and looking for the namespaces that matches “controller-”

  2. Once the namespace is found you will need to create an updated changes.yaml file with the following content.

- apiGroups:
  - ""
  - pods
  - list
  - get
  - watch
- apiGroups:
  - ""
  - services
  - get
- apiGroups:
  - ""
  - pods/portforward
  - create
  - get
  1. Apply the changes.yaml to the proxy role used by juju using the namespace identified in the first step.
kubectl patch role controller-proxy  -p "$(cat changes.yaml)" -n <controller-namespace>

How do I install Juju?

The best way to get a specific release of Juju is to install the snap from the appropriate channel. snap info juju will give you a list of the current channels and the versions published in them. For the latest stable release of Juju:

sudo snap install juju --classic --channel=2.9

The Juju CLI is available for a variety of platforms, including Windows and macOS. Refer to the installation documentation for details.

How do I upgrade?

There are three binaries that make up a Juju deployment - the client, the server and the agents. To upgrade a running system:

Upgrade the client

Make sure you have the version of the Juju CLI that you want running across the system (controller and agents in any deployed models). If you installed the Juju snap, it will automatically be updated daily from the channel you selected, but you might want to sudo snap switch juju --channel=2.9 for example, to get a particular version. To get the latest binary from your channel:

snap refresh juju --channel=2.9

Upgrading the Juju client through other channels

Check version

Make sure that you’re using the Juju version you want.

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

Upgrade a Juju server

You can see which servers your client knows about, and their versions, with this command:

juju controllers
Controller  ...  Version
azure*      ...  2.8.3  
jaas        ...  2.7.6  

You can instruct a server to upgrade itself to the latest version:

juju upgrade-controller <controller>

How to upgrade the controller

Upgrade deployed agents

Each running model includes a set of Juju agents which manage the communication between your charms and the Juju server. Your model agents remain at the same version until you ask to upgrade them.

juju upgrade-model <model>

How to upgrade your model(s)

Further instructions

For detailed information about the upgrade process please see:

Feedback Appreciated!

Let us know how you’re using Juju! Please ask questions on discourse.charmhub.io, tweet us @juju_devops with the hashtag #juju_devops, and chat with us at #juju on Freenode.

1 Like

Should we really use --agent-stream=proposed for this 2.9.3 release?

1 Like

Probably copied from the notes prior to official blessing.

Agents are available in the released streams; I will amend.

1 Like