In progress: This document will be completed as the release hits 2.8.0.
The Juju 2.8 series brings several features to the Juju community.
Improved resource usage
Juju agents (
jujud processes) now use less memory, particularly for long-lived models.
Several internal changes have led to speed improvements while executing hooks. This means that all Juju operations should run faster on Juju 2.8 than previous versions.
As an implementation detail, the Juju controller stores its state within a database. Research carried out through the cycle identified areas where unnecessary database calls were being made.
Fewer, more informative log messages
Juju 2.8 increases the default logging level to INFO. This allows debugging information to be accessible, but not presented to users by default.
Custom machine images are now easier to deploy
You are now able to specify virtual machine images that Juju should consider when provisioning new compute capacity. The
juju metadata add-image command informs Juju that an image should be considered when the series is selected.
juju metadata add-image --series <series> <image-id>
Here are some provider-specific guides for identifying which
<image-id> to select:
- AWS EC2 refers to images as “AMIs” (Amazon Machine Image). AMIs are region-specific.
- Google Compute Engine https://cloud.google.com/compute/docs/images
- Azure Machine Images
Juju 2.8 improves support for adding MS Windows machines via Windows Remote Management (WinRM).
Features added to the core
Juju continues to strengthen its ability to support Kuberentes-based workloads.
Charms no longer need a persistent volume for charm state
The Juju controller can now store charm state in
juju-db (an instance of MongoDB deployed alongside the Juju controller), rather than on disk where the charm is located.
This removes the requirement for Juju to provision a persistent volume for every charm operator that is deployed.
To take advantage of this feature, charms declare their
metadata.yaml to this release:
# metadata.yaml min-juju-version: 2.8.0
For such charms, Juju will no longer create a k8s PV when deploying the operator pod to run the charm.
Developer preview: This feature is available for experimentation via a controller feature flag, but is subject to further refinement.
Juju now supports the ability for charms’ workloads to run within the charm’s workload pod itself. As background, Juju co-deploys an “operator pod” to execute hooks alongside workloads.
An “operator”, as a k8s concept, is defined as:
… clients of the Kubernetes API that act as controllers for a Custom Resource. An operator uses the k8s APIs to automate and control the provisioning of resources in the cluster.
Storage on Deployment and DaemonSet workloads
Extended volume support and other features
- ability to define hostpath, emptydir volumes
- volumes backed by secrets and config maps
- define lifecycle or CRDs
- value reference container config
Tracking of resources created outside of Juju
Charms deployed by a Juju application may now create custom resources themselves. These will now be annotated in the same way as any resources created by Juju - with the model and controller UUIDs and application name.
This change allows for simpler management over time. They to be removed when the parent application is removed.
Resource lifetime management
It’s now possible for a charm to allow resources to exceed the charm’s own lifetime.
Sometimes, certain k8s workloads expect that some global resources (eg kubeflow and User profiles) are retained even when the application (or model) which created them is removed.
Charms now define a
juju-resource-lifecycle label. The possible values are:
model, which ties the resource’s lifetime to the lifetime of the model. The resource is deleted when the model is destroyed.
persistent(do not delete even when the model is destroyed)
The default is to delete resources when the application which created them is removed.
Support for running ad hoc commands inside the operator pod
juju run (on the client) and
juju-run (inside a operator or workload pod) now both accept the
--operator argument to specify that the requested script should be run on the operator pod rather than the workload pod.
Webhook global names
Juju will prefix any global resources with the model name to ensure applications deployed multiple times into different namespaces do not conflict. However, some workloads which Juju has no control over (yet) expect web hooks (in particular) to have fixed names. Charms can now define an annotation on mutating nad validating webhooks to disable this name qualification:
annotations: juju.io/disable-name-prefix: "true"
Until Juju 2.7, organisations running vSphere would require Juju administrators to be provided with write permissions at the datacenter level. Organisations would prefer to be able to give access to users to a bootstrap controller in a specific location without opening up the whole datacenter.
The current behaviour of the vSphere provider is to create virtual machines within in a top-level folder in the specified datacenter named “Juju Controller ”. Template VMs are under another folder called “juju-vmdks”.
Juju now appropriately models OpenStack clouds with with multiple NIC devices or “spaces”.
New Actions UX
Actions have gained a new user experience (UX), including the ability to cancel a running action. Making use of these new commands requires setting an environment variable,
JUJU_FEATURES, as they conflict with the hold behaviour.
New capability for charms: controller-backed key/value store
Charms now have the ability to request that the Juju controller store data between hook invocations. This should avoid the need for charms to modify the charm directory. This enables charms to be deployed as “stateless” workloads on clouds that may not have storage support, such as some Kubernetes clusters.
Three hook tools have been introduced:
||Modify values in the store.|
||Load a value from the|
||Remove a key/value pair from the store.|
Juju enforces the following limits during
- Keys cannot exceed 256 bytes
- Values cannot exceed 64kb
- Total size of persisted charm state cannot exceed the limit specified by the
max-charm-state-sizecontroller configuration option. Its default is 2MB.
This feature is yet to be integrated into charming frameworks, but is available for experimentation today.
New hook family:
A symmetric hook family to
*-relation-broken. Allows charms to receive data from the relation, regardless of the presence of other units.
It should also allow charms to not needlessly enter the
blocked state when a relation has been created, but before it the first unit is available.
A comment in the original bug report explains some of the rationale:
This is fired as soon as a relation is established, and before any units are accounted as joined as far as the local unit agent knows about. This hook fires once for each relation ID, and is the missing complement of -relation-broken.
Hook execution sequence
Changes have been made to the sequence of hooks that are fired.
Trigger: Unit agent process creation
start hook is now executed when the unit agent (which appears as
jujud agent in the output from
Trigger: Unit install
Need to clarify what “unit install” is…
Trigger: Removing unit
Removal of “legacy” leases
Juju now exclusively uses the Raft consensus algorithm to implement high-availability controllers.
Juju client libraries
pylibjuju project has released been updated to support Juju 2.8.0
pip install -U juju
New in Juju 2.8 is the Juju Dashboard. A shift in direction from the preceding Juju GUI which had a focus on the deployment of models. The new Dashboard is focused on the operations and observability of your Juju models across one or more controllers.
Model List Overview
Tailored for enterprises and large environments; your primary view in the Juju Dashboard is a list of your models. It provies at a glance, a live, autoupdating overview of the statuses of your systems without having to repeatedly query the status on the command line.
To provide deeper observability into your model you also have access to the Model Details view. It’s here that you’ll find a detailed overview of all the entities in your model, applications, units, machines, and relations.
The topology that was the center of the old GUI hasn’t completely disappeared. We still show you the same representation of your model on this details page complete with application icons and relation connections to give you that same top down view of your models.
What’s Coming Up?
- The topology model is currently a static view, we’ll be re-introducing the ability to position your application icons to allow for a better representation of your model.
- Cross Model Relations have become an increasingly popular feature of Juju so we’ll be highlighting those and providing insight into the relations both in the relations list and in the topology view.
- Surfacing your permissions and disabled-commands.
- From an operations perspective Juju Actions are integral to the day to day operations of most models. We’re going to be investigating how we can surface the actions and provide feedback on their execution.
- When you’re tracking down an issue with a deployment nothing is more important than logs. We’re actively investigating the best approach to surface the various logs that you have access to in your deployment.
- And much much more…
We hope you enjoy using the new Juju Dashboard!
Changes for charms
Juju 2.8 introduces the
remove hook. This is symmetric to
install and provides an opportunity for charms to clean up after the unit has been removed.
This functionality is especially important when multiple charms are deployed to the same machines via placement directives.
juju debug-code sub-command allows charm authors to enter a debugger as a hook is executing. Initial support has been added to the Operator Framework.
We have a vision for what this new dashboard will become and your feedback is integral to that vision. Please feel free to file issues on our GitHub repository or start a discussion. We’re actively seeking input on existing and upcoming features.