This document describes the
config-changed event is emitted in response to various events throughout a charm’s lifecycle:
- In response to a configuration change using the GUI or CLI.
- On networking changes (if the machine reboots and comes up with a different IP).
- Some time between the
installevent and the
startevent in the startup phase of a charm’s lifecycle.
config_changedevent will ALWAYS happen at least once, when the initial configuration is accessed from the charm.)
Callbacks associated with this event should ensure the current charm configuration is properly reflected in the underlying application configuration. Invocations of associated callbacks should be idempotent and should not make changes to the environment, or restart services, unless there is a material change to the charm’s configuration, such as a change in the port exposed by the charm, addition or removal of a relation which may require a database migration or a “scale out” event for high availability, or similar.
Callbacks must not assume that the underlying applications or services have been started.
There are many situations in which
config-changed can occur. In many of them, the event being fired does not mean that the config has in fact changed, though it may be useful to execute logic that checks and writes workload configuration. For example, since
config-changed is guaranteed to fire once during the startup sequence, some time after
install is emitted, charm authors might omit a call to write out initial workload configuration during the
install hook, relying on that configuration to be written out in their
config-changed handler instead.
juju deploy foo
juju add-unit foo
install -> config-changed -> start
|Configure a unit
juju config foo bar=baz