Dmitrii
13 September 2020 19:03
3
Hi Erik,
The <relation-name>-relation-created hook family was added in Juju 2.8 to address some stateful application initialization uses-cases. I think the event lifecycle docs haven’t been updated yet (ping @juju-developers ).
The Juju team is proud to release Juju 2.8.0. We aim to be your preferred tool for writing operators, software that manages software, whether your hosting infrastructure is Kubernetes, in the cloud or on-premise.
2.8 Highlights
New Features
Juju 2.8.0 includes extra features for people using Juju as well as those writing charms for Juju.
OpenStack models now have multi-NIC support
The new Juju Dashboard replaces the Juju GUI.
A new hook family, *-relation-created, has been introduced to not…
juju:develop ← achilleasa:dev-fire-relation-created-hooks
opened 06:31PM - 20 Mar 20 UTC
## Description of change
This PR enables the uniter to trigger a new hook typ… e called `xyz-relation-created` which:
- fires **after** `install` and **before** `xyz-relation-joined`
- is allowed to fire **before** any of the remote units come online.
The new hook is **guaranteed** to fire **before** any leadership hook for **peer** relations and for any **non-peer relation already established at that point**. For non-peer relations established at a later point in time, the hook will fire once the relation has been established.
In order to implement the above semantics, a new resolver had to be created and invoked prior to the leadership-hook resolver. This proved to be a non-trivial task since the new resolver needs to share internal state with the original relation resolver. In particular, the original relation resolver was nothing more than a proxy to a pluggable interface called `Relations` which was actually responsible for implementing the hook triggering logic. The same interface also provides the relation-specific implementation for the `PrepareHook` and `CommitHook` calls that the resolver callbacks invoke.
The solution followed by this PR is to effectively refactor (for more details see the commit log for a73d509) the interface to only handle state-related tasks and move the hook logic back to the resolver. To make the code easier to follow, the `Relations` interface (in `worker/uniter/relation`) has been renamed to `StateTracker` to better convey its purpose.
The `relation-created` hook provides information about the remote application that was related (note that local == remote for peer relations). For symmetry, the `relation-broken` hook has been updated to also include the same information (this information was lost prior to this PR so it was not made available).
## QA steps
**Important**: before running the following steps, make sure you have dialed up the logging level on your model by running:
```
juju model-config logging-config='<root>=ERROR;juju.worker.uniter.operation=DEBUG'
```
### Scenario 1: pre-established non-peer relations
```console
$ juju deploy -n2 wordpress && juju deploy mysql && juju add-relation wordpress mysql
# Wait for everything to settle and check the logs:
# (for the leader wordpress unit)
$ juju debug-log --replay --include unit-wordpress-0 | grep 'committing operation' | cut -d '"' -f2
install cs:wordpress-0
run install hook
run relation-created (0; app: wordpress) hook <-- new (peer)
run relation-created (2; app: mysql) hook <-- new (non-peer)
accept leadership
run leader-elected hook <-- xxx-created before leader-elected
run config-changed hook
run start hook
run relation-joined (0; unit: wordpress/1) hook
run relation-changed (0; unit: wordpress/1) hook
run relation-joined (2; unit: mysql/0) hook
run relation-changed (2; unit: mysql/0) hook
run update-status hook
# (for the non-leader wordpress unit)
$ juju debug-log --replay --include unit-wordpress-1 | grep 'committing operation' | cut -d '"' -f2
install cs:wordpress-0
run install hook
run relation-created (0; app: wordpress) hook <-- new (peer)
run relation-created (2; app: mysql) hook <-- new (non-peer)
run leader-settings-changed hook
run config-changed hook
run start hook
run relation-joined (0; unit: wordpress/0) hook
run relation-changed (0; unit: wordpress/0) hook
run relation-joined (2; unit: mysql/0) hook
run relation-changed (2; unit: mysql/0) hook
run update-status hook
# (for mysql unit)
$ juju debug-log --replay --include unit-mysql-0 | grep 'committing operation' | cut -d '"' -f2
install cs:mysql-58
run install hook
run relation-created (1; app: mysql) hook <-- new (peer)
run relation-created (2; app: wordpress) hook <-- new (non-peer)
accept leadership
run leader-elected hook
run config-changed hook
run start hook
run relation-joined (2; unit: wordpress/0) hook
run relation-changed (2; unit: wordpress/0) hook
run relation-joined (2; unit: wordpress/1) hook
run relation-changed (2; unit: wordpress/1) hook
run update-status hook
run update-status hook
```
### Scenario 2: establishing peer relations for already-deployed units
```console
$ juju deploy wordpress && juju deploy mysql
# Wait for them to become ready and *then* relate them
$ juju add-relation wordpress mysql
# Wait a bit and then remove relation
$ juju remove-relation wordpress mysql
# Check the logs
$ juju debug-log --replay --include unit-wordpress-0 | grep 'committing operation' | cut -d '"' -f2
install cs:wordpress-0
run install hook
run relation-created (0; app: wordpress) hook <-- new peer
accept leadership
run leader-elected hook
run config-changed hook
run start hook
run relation-created (2; app: mysql) hook <-- late-added relation
run relation-joined (2; unit: mysql/0) hook
run relation-changed (2; unit: mysql/0) hook
run relation-changed (2; unit: mysql/0) hook
run update-status hook
run relation-departed (2; unit: mysql/0) hook
run relation-broken (2; app: mysql) hook
$ juju debug-log --replay --include unit-mysql-0 | grep 'committing operation' | cut -d '"' -f2
install cs:mysql-58
run install hook
run relation-created (1; app: mysql) hook <-- peer relation
accept leadership
run leader-elected hook
run config-changed hook
run start hook
run relation-created (2; app: wordpress) hook <- late-added relation
run relation-joined (2; unit: wordpress/0) hook
run relation-changed (2; unit: wordpress/0) hook
run update-status hook
run relation-departed (2; unit: wordpress/0) hook
run relation-broken (2; app: wordpress) hook
```
### Scenario 3: relation with no units
```console
$ juju deploy wordpress && juju deploy mysql
$ juju remove-unit mysql/0
# Wait for things to settle until juju status looks like this:
$ juju status
App Version Status Scale Charm Store Rev OS Notes
mysql waiting 0 mysql jujucharms 58 ubuntu
wordpress active 1 wordpress jujucharms 0 ubuntu
Unit Workload Agent Machine Public address Ports Message
wordpress/0* active idle 1 10.241.88.191 80/tcp
# Create a relation and check the logs
$ juju add-relation wordpress mysql
$ juju debug-log --replay --include unit-wordpress-0 | grep 'committing operation' | cut -d '"' -f2
install cs:wordpress-0
run install hook
run relation-created (0; app: wordpress) hook <-- peer relation
accept leadership
run leader-elected hook
run config-changed hook
run start hook
run relation-created (2; app: mysql) hook <- non-peer relation with no remote units
```
### Scenario 4: leader sets peer relation data in relation-created hook
```console
$ echo '#!/bin/sh
echo $0
is_leader=`is-leader`
if [ "${is_leader}" = "True" ]; then
echo "setting app databag for peer relation as the leader"
relation-set --app answer=42
fi' > testcharms/charm-repo/quantal/all-hooks/hooks/self-relation-created
$ juju deploy ./testcharms/charm-repo/quantal/all-hooks -n 2
# Wait for things to settle and check peer relation data and check the peer app databag
$ juju run --unit all-hooks/0 'relation-get -r 0 --app=True - all-hooks'
answer: "42"
$ juju run --unit all-hooks/1 'relation-get -r 0 --app=True - all-hooks'
answer: "42"
```
## Documentation changes
We need to update our 2.8 docs to indicate the order of relation-created hooks.
## Bug reference
https://bugs.launchpad.net/juju/+bug/1859769
relation-created is particularly useful in a scenario where you want to use application relation data (introduced in 2.7.0) on a peer relation which is supposed to replace leader data - bug Bug #1859769 “[2.7.1] peer relation (and its app relation data) ...” : Bugs : Canonical Juju has some particularities as to why that was introduced.
Operator Framework does not even expose leader data and expects that developers use app relation data with peer relations.
I think the diagram is quite useful for understanding main loop-like semantics of how units operate. Looking at it now, I think it could be enhanced by adding some information about sources of events and the context available in them.
Event objects in the framework do a better job at exposing the context than what was available before:
https://ops.readthedocs.io/en/latest/index.html#ops.charm.RelationCreatedEvent
https://ops.readthedocs.io/en/latest/index.html#ops.charm.ActionEvent
1 Like
