Statuses

The charm has not been granted permission to control the Kubernetes StatefulSet partition

pause_after_unit_refresh is not set to all, first, or none

On machines, in certain cases, it is not possible to determine if a refresh is in progress.

For example, it is not (easily) possible to immediately differentiate between the following cases:

In both of these examples, after a few Juju events (usually a few seconds), it will be possible to determine if a refresh is in progress—​as long as no units' charm code is raising an uncaught exception.

On machines, after the user runs juju refresh and before any workload is refreshed, the new charm code checks if it supports refreshing from the previous workload & charm code version.

If the refresh is not supported, no workload will be refreshed.

This status will only be displayed if an incompatible refresh has not been forced on the first unit to refresh with the force-refresh-start action.

The leader unit will also log an INFO level message to juju debug-log. For example:

If the Kubernetes StatefulSet partition has been set to allow the last unit to refresh, the refresh cannot be halted using the pause_after_unit_refresh config option.

At that point, a rollback is only possible if Kubernetes decides not to refresh the last unit (because the up-to-date units' pod readiness probes have not all succeeded) and the user runs juju refresh.

Refresh in progress for a single-unit application

(pause_after_unit_refresh is set to all or set to first and the second unit has not started to refresh)

(pause_after_unit_refresh is set to none or set to first and the second unit has refreshed or started to refresh)

If the user runs juju refresh with --revision and without --resource, the workload(s) will not be refreshed. This is not supported—​Data Platform charms pin a specific workload version for each charm code version.

Similarly, these additional cases are not supported and will have the same user experience:

This status will only be displayed on the first unit to refresh and only if the workload has not been forced to (attempt to) start with the force-refresh-start action.

The unit will also log an ERROR level message to juju debug-log. For example:

On Kubernetes, after the first unit refreshes and before that unit starts its workload, that unit (new charm code) checks if it supports refreshing from the previous workload & charm code version.

If the refresh is not supported, that unit will not start its workload.

This status will only be displayed on the first unit to refresh and only if the workload has not been forced to (attempt to) start with the force-refresh-start action.

The unit will also log an INFO level message to juju debug-log. For example:

Regardless of whether the user runs the pre-refresh-check action before juju refresh, the charm will run pre-refresh health checks & preparations after juju refresh—​unless it is a rollback.

On machines, the checks & preparations run before any workload is refreshed. These checks & preparations are identical to those in the pre-refresh-check action—​except that they are from the new charm code version.

On Kubernetes, the checks & preparations run after the first unit has refreshed. These checks & preparations are a subset of those in the pre-refresh-check action (since some checks & preparations may require that all units have the same workload version). These checks & preparations run on the refreshed unit (i.e. on the new charm code version).

This status will only be displayed on the first unit to refresh and only if the workload has not been forced to refresh (machines) or to attempt to start (Kubernetes) with the force-refresh-start action.

The unit will also log an ERROR level message to juju debug-log. For example: