Event 'config-changed'

doc
,
1

Event > List of events > Lifecycle events > config-changed

Source: ops.ConfigChangedEvent

This document describes the config-changed event.

Contents:

Emission sequence

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 install event and the start event in the startup phase of a charm’s lifecycle.
    (The config_changed event 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.

Scenario Example Command Resulting Events
Create unit juju deploy foo
juju add-unit foo 		install -> config-changed -> start
Configure a unit juju config foo bar=baz config-changed
2
3

@jameinel could you take a look at this doc please? It says (as derived from docstrings) that relation-joined and relation-changed should be triggering config-changed. But a quick juju debug-log inspection shows otherwise

image
image929×693 104 KB

Is this a bug in juju or in the docs (or in the tool I’m using to scrape the logs)?

4

We talked in Mattermost and confirmed that Juju, indeed, doesn’t trigger config-changed based on the events that were listed in the docstring.

1 Like
5
6

I think it would help if we reword:

I think that a config-change event is guaranteed to be queued after an install event, but it is not guaranteed to occur “immediately after” the install event. For example, here is a show-status-log from a random deployment of kubeflow-profiles (truncated a bit for readability):

Time                        Type       Status       Message
02 Feb 2023 12:48:12-05:00  juju-unit  allocating   
02 Feb 2023 12:48:12-05:00  workload   waiting      installing agent
02 Feb 2023 12:48:22-05:00  workload   waiting      agent initializing
02 Feb 2023 12:48:28-05:00  juju-unit  executing    running install hook
02 Feb 2023 12:48:30-05:00  juju-unit  executing    running kubeflow-profiles-relation-created hook
02 Feb 2023 12:48:36-05:00  juju-unit  executing    running kubeflow-profiles-relation-created hook
02 Feb 2023 12:48:37-05:00  juju-unit  executing    running leader-elected hook
02 Feb 2023 12:48:39-05:00  juju-unit  executing    running kubeflow-kfam-pebble-ready hook
02 Feb 2023 12:48:40-05:00  juju-unit  executing    running config-changed hook
02 Feb 2023 12:48:42-05:00  juju-unit  executing    running start hook

Maybe we can change the text to say something like how the config-changed event is queued after an install event and will be handled in the regular queuing sequence, which might mean other hooks fire between install and config-changed? Or some version of that, but better written? :slight_smile:

7

Done! Thanks