Starting with Juju 4.0, Juju will no longer be offering the ability to upgrade a machine base in situ. This feature was only present for machine based workloads and was not supported for container based workloads (k8s).
A specification is being created to define a common workflow for charms to mitigate divergent workflows when upgrading across bases.
Why the change?
Cloud paradigms are tending towards ephemeral workloads. Juju is moving towards this direction and the need for this concept within Juju is being diminished.
Who is this likely to affect?
Charms and users of Juju that want to upgrade to a new base of a machine.
What action does it require from charm authors?
The Juju team is defining a new specification for creating a common workflow for recommended upgrade scenarios. An announcement to that effect will be done nearer the launch of Juju 4.0.
This is just referencing the ability to upgrade the base of a machine - for example upgrading a 22.04 machine to 24.04 machine. Charm/workload upgrades will still work, provided they don’t transition the base (though transitioning bases will work fine on Kubernetes).
My understanding is that spec will be about what the process looks like when the base for a machine charm changes mid-track.
For example, if you have a charm on latest/stable using the ubuntu@22.04 base, what’s the upgrade process if the publisher releases a new revision with the ubuntu@24.04 base?
