We’re working on fixing a race condition with how the charm operator setups up the workload pods. The issue manifests itself in that sometimes bundle deployments can stall. Also, upgrading a charm will not propagate any new action scripts.
We now support storage for stateless workloads like DaemonSet and Deployments.
There’s experimental support added for deploying charms as k8s operators.
Backup and Restore
Building on the work done last week to deliver a new restore utility for testing, we are close to supporting the ability to downgrade a controller to a previous Juju version. Previously this was rejected outright as something that could not be done.
Openstack & Goose.v2
Ongoing work to ensure that on the shutdown of an Openstack instance, all Juju created ports are in fact deleted at the right time. Included changes to the Goose.v2 client to enable users of the library the ability to change the default http headers.
Ongoing integration tests for the Manual and Openstack provider concerning spaces.
Controller-backed charm/agent state
As part of our ongoing work to move the locally (on disk) persisted charm and (unit) agent state to the controller, we have introduced a quota limit mechanism to prevent misbehaving charms from exploiting this new future to store BLOB/CLOB data to the controller.
More specifically the following limits are enforced when you mutate the charm state for a unit:
Keys cannot exceed 256 bytes
Values cannot exceed 64k
Total size of persisted charm state cannot exceed an operator-configurable limit. This limit is tunable via the max-charm-state-size controller config option and defaults to 2M.
In addition, a separate (also operator-configurable) limit is enforced when mutating the unit agent state. This limit is tunable via the `max-agent-state-size controller config option and defaults to 512k.
Bugfixes and Internal Changes
#1869883 Kubernetes Multicloud controller passing the wrong IP to external Kubernetes