The Juju team is excited to release Juju 3.6.0.
Our mission continues to be your preferred tool for writing operators, software that manages software, whether your hosting infrastructure is Kubernetes, in the cloud or on-premises.
Release Highlights
LTS release
The 3.6 release series is an LTS release, as this is the final minor (the ‘x’ in 3.x) release before 4.0. For minor versions, we provide a minimum of 6 months bug-fixing support followed by 3 months support for security fixes. For LTS releases, such as this, we provide 5 years support for security fixes.
See Roadmap & Releases for more details.
Rootless charms on k8s
On a quest to support deploying rootless charms, in Juju 3.5 support was added to allow workload containers in Kubernetes charms to run as a non-root user.
A continuation of that quest, from Juju 3.6.0 you can now also run the charm container as a non-root user. Added to charm metadata is a new top-level field, charm-user, which controls which user the charm is run under. This is only supported on Kubernetes; on machines it has no effect as of 3.6.
It supports three values: root, sudoer and non-root.
charm-user: rootruns the charm as the root user.charm-user: sudoerruns the charm as a user that can use sudo to run commands as root.charm-user: non-rootruns the charm as a user that is not root and does not have access to sudo.
Azure Managed Identities
It’s now possible to configure Juju to assign a User Managed Identity to Juju controllers. This allows the controllers to gain the privileges they need to manage resources in the cluster without having to store an actual end user credential on the controller. Traditionally, upon bootstrap, Juju would copy the user’s credential secrets to the controller and use that when making API calls to the cloud. Now, the fact that a User Managed Identity is attached to each controller means that this is no longer necessary; the controller gets the authorization it needs to manage cloud resources from the managed identity.
The recommended way to use this feature is described in the feature announcement here and in the context of documentation of Juju credentials for Azure here.
Idempotent Secrets
Updating a secret with the same content as the latest revision was creating a new revision each time. With this release, calling secret-set multiple times with the same content as that of the latest revision is now idempotent.
Noteworthy
A few fixes and changes including: