Juju continues to develop strongly. The features described here are not fully documented, but indicate where the team has been focusing its efforts.
- Juju 2.7.4 is an important bugfix release. All users on 2.7.3 are strongly advised to upgrade their controllers and models to this new version.
Backup and restore
Work continues to streamline the process of backing up and restoring a Juju controller and its models.
- enhanced backup file metadata
- changed backup file to be versioned
- added verification steps to prior to performing restore (eg. mongo health check, intra-controller connectivity check, backup file compatibility check)
Kubernetes support strengthens.
- Work is continuing on a Juju admission controller endpoint. This will enable label resources created outside Juju
- Service accounts now support both global and namespace scoped roles
- Introduce a global resources lifecycle (CustomResourceDefinitions and others). Although they break the namespacing introduced by a Juju model, global resources are available for teams using Kubernetes.
- Tidy up of DaemonSet support. This is a new feature that will enable charms to create DaemonSet applications. The
scale-applicationcommand doesn’t make sense in this context. They’re automatically provisioned to every node in the cluster.
k8s controller upgrades
There’s no metadata for the docker images used for the Juju agents, which meant that
agent-stream could not be used to control the desired risk when upgrading. Work was done to use the published simple streams metadata for non-k8s agents to also guide the selection of which Juju operator image tag to select.
Uniter refactoring work
- After a hook exits with a 0 status code, the uniter will now push all required state mutations to the controller using a single API call and apply them in a single transaction.
- The uniter now detects machine reboots and triggers an implicit start hook to notify charms. The start hook will only be triggered after a reboot (simply restarting unit agents has no effect) and only if the uniter’s state reports the charm as already started.
New build process
The build process is being enhanced to use the new snapcraft remote-build feature. This will unlock the ability to:
- migrate to go mod
- use recent versions of Go
- simplify Juju snap build process, eg single source all snap artefacts in core Juju repo
- work in progress, will be used to build the 2.8 beta
- relation-get --app fails on non-leader units (peer relations)
- Makefile looks for info about ‘jujud’ before it builds it
- Recreate exec k8s client on failure
- newly boostrapped controllers fail to obtain signed letsencrypt certificate
- Juju show-action-status does not show all actions by default
- failed to deploy bundle with “suitable availability zone for machine not found”
- and others
Pull requests merged:
- Dispatch k8s actions
- Fix 1864900 ACME v2 autocert support
- Protect against nil profile from the charm.
- Unit Test to Cover Nil Profile Fix
- Recreate exec k8s client on failure
- Spaces API Facade Method - SubnetsByCIDR
- Fix 1866658 jujud called in Makefile before built
- Fix a watcher race that was in the ControllerAddressesSuite.
- Ensure k8s juju upgrades select correct agent version.
- Speed up the processing of machines in juju status.
- charm dispatch changes in uniter
- Extend RBAC under kubernetesResources to support multi roles/cluster
- [dev] Run start hook on reboots
- Refactor tools finder
- provider/azure: update azure-sdk-for-go.
- 2.7 k8s controlling lxd 1866623
- Fix 1865455 juju show-action-status not listing all
- Refactor apiserver ToolsFinder() and ToolsGetter() to take a newEnviron func
- Fix 1860083 suitable availability zone for machine not found
New Website: juju.is
Guide: How to run any hook with a remote context