Event > List of events> Relation events >
See also: A charm’s life, The lifecycle of charm relations, Discussion on hooks: relation-departed and relation-broken, Relation-broken hook not running in peers relation, Charm hooks
juju v.3.0, ‘integrations’ were called ‘relations’. Remnants of this persist in the names, options, and output of certain commands, and in integration event names.
relation-joined is emitted when a unit joins in an existing relation. The unit will be a local one in the case of peer relations, a remote one otherwise.
By the time this event is emitted, the only available data concerning the relation is
- the name of the joining unit.
private-addressof the joining unit.
In other words, when this event is emitted the remote unit has not yet had an opportunity to write any data to the relation databag. For that, you’re going to have to wait for the first
From the perspective of an application called
foo, which can relate to an application called
|Scenario||Example Command||Resulting Events|
For a peer relation,
<peer relation name>-relation-joined will be received by peers some time after a new peer unit appears. (And during its setup, that new unit will receive a
<peer relation name>-relation-created).
relation-joined can fire multiple times per relation, as multiple units can join, and is the exact inverse of
That means that if you consider the full lifecycle of an application, a unit, or a model, the net difference of the number of
*-relation-joined events and the number of
*-relation-departed events will be zero.
Observing this event in Ops
ops, you can observe this event like you would any other:
# in MyCharm.__init__ self.framework.observe( self.on.foo_relation_joined, self._on_foo_relation_joined)
The RelationJoinedEvent object does not expose any specific attributes, but the
unit attribute always refers to the unit that just joined the relation.