Looking at the Juju code, entries in mongodb for relation settings are created earlier than the scope doc so the charms only know about relations for which there are already relation settings present.
I am going to add Juju to comment - if ingress-address is not guaranteed to be present in relation settings during the handling of <relname>-relation-joined then it would be best to document it for both IAAS and CAAS models. I couldn't find any reference to this behavior in the current docs.
There was a similar bug for K8s charms:
https:/ /github. com/johnsca/ juju-relation- mysql/issues/ 5
Looking at the Juju code, entries in mongodb for relation settings are created earlier than the scope doc so the charms only know about relations for which there are already relation settings present.
https:/ /github. com/juju/ juju/blob/ juju-2. 7.8/apiserver/ facades/ agent/uniter/ uniter. go#L1461- L1483 (ingress-address and private-address get placed into relation settings) /github. com/juju/ juju/blob/ juju-2. 7.8/state/ relationunit. go#L112- L150 (transaction ordering: settings go first then goes the scope doc)
https:/
However, looking more closely, inability to retrieve address information is not an error condition (merely a warning):
https:/ /github. com/juju/ juju/blob/ juju-2. 7.8/apiserver/ facades/ agent/uniter/ uniter. go#L1476- L1479
There seem to be conditions in NetworksForRelation where an address may not be available:
https:/ /github. com/juju/ juju/blob/ juju-2. 7.8/apiserver/ facades/ agent/uniter/ networkinfo. go#L281- L308
And these two Juju bugs are related to this:
https:/ /bugs.launchpad .net/juju/ +bug/1830252 /bugs.launchpad .net/juju/ +bug/1848628
https:/
I am going to add Juju to comment - if ingress-address is not guaranteed to be present in relation settings during the handling of <relname> -relation- joined then it would be best to document it for both IAAS and CAAS models. I couldn't find any reference to this behavior in the current docs.