Juju is a large, complex software system. Some of its complexity is inherent in the domain; some is due to the accumulation of features over time that service specific needs in the charm ecosystem.
The Juju team is always striving against this accumulated complexity, so that we can present a coherent conceptual story to our cloud customers and charming ecosystem counterparts.
The behaviour we’re considering here is Juju’s auto-population of network keys in relation data-bags.
How Juju does it now
When a Juju unit enters the scope of a relation, we automatically determine some network information for that unit. We do this by interrogating the link-layer devices and IP addresses of the machine/VM/container where that unit resides, and factoring the bound space (if any) for the relation’s endpoint.
We use the result to set the following keys in relation data, while making a best effort attempt to keep this information current by recomputing the relation network data each time the unit is issued a config-changed hook:
- ingress-address; the address that related counterparts should use to access this unit’s workload.
- egress-subnets; the networks from which connections by this unit’s workload will originate.
- private-address; always the same as ingress-address, retained for backward compatibility.
The tooling used here is exactly the same as the network-get hook tool, already available to charms.
Issues with this approach
- Juju does not have the knowledge needed to present the best network configuration for the charm. Instead, we abbreviate the information, discounting data such as interface name and MAC address, and in the case of multiple addresses, just choose the first.
- The “best effort” approach for keeping the settings up-to-date results in redundant reassessment of network data, and in the case of some changes such as rebinding, no update, leading to potential discrepancies.
What’s next: Juju as the enabler
Our long-term strategy is to form Juju operation from its core concepts, rather than from many pieces of individual detail.
In Juju’s future design, charms should assume the responsibility for calling network-get and setting suitable relation data, as the charm is in the best position to determine necessary network information and when it should be updated.
To be future-proof, we encourage charmers to use network-get to set their own network data within the relation-created hook, maintaining the data over time as appropriate.
Following discussions with individuals and teams, we believe the existing behaviour should be retained in Juju 4.0, with the intention to remove it in a later release.
The only change in 4.0 will be the deprecation of the legacy private-address key.
Please reach out to myself or other members of the Juju team if you have any questions.