Event > List of events > Lifecycle events >
upgrade-charmSource:
ops.UpgradeCharmEvent
The upgrade-charm event is emitted for a unit that is undergoing an upgrade.
The event is emitted after the new charm code has been unpacked - therefore this event is handled by the callback method bound to the event in the new codebase.
The associated callback should be used to reconcile the current state written by an older version into whatever form is required by the current charm version. An example of a reconciliation that needs to take place is to migrate an old relation data schema to a new one.
- Typically, operations performed on
upgrade-charmshould also be considered forinstall. - In some cases,
config-changedcan be used instead ofinstallandupgrade-charmbecause it is guaranteed to fire after both. - Note that you cannot upgrade a Charmhub charm to the same version. However, upgrading a local charm from path works (and goes through the entire upgrade sequence) even if the charm is exactly the same.
Contents:
Emission sequence
| Scenario | Example command | Resulting events |
|---|---|---|
| Upgrade kubernetes charm | juju refresh |
stop (old charm) → upgrade-charm (new charm) → config-changed → leader-settings-changed (if the unit is not the leader) → start → *-pebble-ready |
| Upgrade machine charm | juju refresh |
upgrade-charm → config-changed → leader-settings-changed (if the unit is not the leader) → start |
| Attach resource | juju attach-resource foo bar=baz |
(same as upgrade) |
An upgrade does NOT emit:\
- any relation events (unless relation data is intentionally modified in one of the upgrade sequence hooks)\
leader-elected
Observing this event in Ops
In Ops, you can observe this event like you would any other:
# in MyCharm.__init__
self.framework.observe(self.on.upgrade_charm, self._upgrade_charm)
The upgrade_charm event object does not expose any specific attributes.