Call for testing! Juju 2.5 RC 2
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 RC 2 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!
Juju 2.5 rc2 changes
Important fixes in this release
- LP #1791715 - juju does not support --to placement directive in bundles
- LP #1806442 - primary charm with a customized lxd profile fails
- LP #1804669 - Charm channel isn’t used on upgrade-charm
Additional bugs fixed can be found in the milestone page.
Juju 2.5 Updates
Kubernetes workloads support
Juju has been able to install a Kubernetes cluster for a while now. However, only until 2.5 is Juju able to take a pre-existing cluster and add it to its list of backing clouds. This renders the cluster available for charm deployment. Kubernetes-specific charms are naturally required.
Documentation: http://docs.jujucharms.com/devel/clouds-k8s.html
At this time the Charm Store is still getting updated to host Kubernetes-specific charms. Testing of this feature requires using the staging Charm Store for now. This is noted in the above documentation.
Extra resources:
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: https://docs.jujucharms.com/devel/clouds-lxd-advanced
Tips on setting up the LXD cluster networking: https://discourse.jujucharms.com/t/manual-network-setup-for-lxd-clustering/261
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: https://docs.jujucharms.com/devel/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.
Documentation: http://docs.jujucharms.com/devel/charms-bundles.html#saving-a-bundle
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.
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.
Documentation: http://docs.jujucharms.com/devel/charms-bundles.html#comparing-a-bundle-to-a-model
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: https://docs.jujucharms.com/devel/clouds-lxd-advanced
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
The Oracle cloud has been updated and now supports Oracle Cloud Infrastructure (OCI) as a cloud.
If you wish to use the older legacy cloud you can find it listed as “OCI Classic” .
Documentation: https://docs.jujucharms.com/devel/clouds-oci
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.
Documentation: https://docs.jujucharms.com/devel/help-openstack#adding-an-openstack-cloud
Adding zones as a valid constraint
You can now select one or more zones to be a constraint on the deployment. If you wish to use a subset of the available zones you can list them at deploy time and all units will respect that selection over time.
Documentation: https://docs.jujucharms.com/devel/charms-constraints
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 #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
- 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
- LP #1811287 - Juju 2.5 fails to deploy canonical-kubernetes charm in AWS
- LP #1811058 - Offers from k8s models do not exist
- LP #1809478 - charm with storage gets stuck initialising on aws
- LP #1783419 - create fstab entry when storage is attached
- LP #1765959 - storage provider does not support dynamic storage
- LP #1808947 - Unable to destroy model, stuck on “state changing too quickly; try again soon”
Additional bugs fixed can be found in the milestone page.
Known issues
- LP #1808515 - updating a charm with a LXD profile, directly after deploying a charm can prevent any new upgrades of the same charm
- LP #1808551 - model migration fails when using a previous client and breaks current client
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 --candidate
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.