The Juju team is proud to release Juju 2.9.8. 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 important fixes
- LP#1924416 - Juju fails to deploy mysql-k8s charm with its image resource
- LP#1934180 - Juju 2.9 failing to create ClusterRoleBinding
- LP#1924707 - Juju interprets caas-image-repo containing port number incorrectly
Additional bugs fixed can be found in the milestone page.
The 2.9.8 release introduces support for bootstrapping and deploying workloads to Equinix cloud. To try out the new provider:
juju update-public-clouds --clientto ensure that provider API endpoint list is up to date.
- Add a credential for the equinix cloud (
juju add-credential equinix). You will need to specify your equinix project ID and provide an API key. You can use the equinix console to look up your project ID and generate API tokens.
- Select a metro area and bootstrap a new controller. For example to bootstrap to the Amsterdam data-center you may run the following command:
juju bootstrap equinix/am.
- Due to substrate limitations, the equinix provider does not implement support for firewalls. As a result, workloads deployed to machines under the same project ID can reach each other even across Juju models.
- Deployed machines are always assigned both a public and a private IP address. This means that any deployed charms are implicitly exposed and proper access control mechanisms need to be implemented to prevent unauthorized access to the deployed workloads.
Labels for logging will allow the aggregation of logs via a label rather than the namespace.
juju model-config "logging-config='#http=TRACE'"
The above will turn on HTTP loggers to trace. This is a new UX feature to help with debugging, it’s not been full worked through Juju yet and might be subject to change.
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
Make sure that you’re using the Juju version you want.
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.
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> --agent-stream=proposed
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)
For detailed information about the upgrade process please see: