See also:

Beginning with juju v.3.0 , relations will be called ‘integrations’.

Charms contain the intelligence necessary for connecting different applications together. These inter-application connections are called relations, and they are formed by connecting the applications’ endpoints. Endpoints can only be connected if they support the same interface and are of a compatible role (requires to provides, provides to requires, peers to peers).

For example, the ‘wordpress’ charmed operator supports, among others, an ‘http’ interface (“provides” the website) and a ‘mysql’ interface (“requires” a database). Any other application which also has such interfaces can connect to this charmed operator in a meaningful way.

Below we see WordPress with relations set up between both MySQL and Apache (a potential relation is shown with HAProxy):


Some of the above application units show unused interfaces. It is the overall purpose of the installation which will dictate what interfaces get used. Some relation types are required by the main charm (‘wordpress’ here) while some relation types are optional. A charmed operator’s entry in Charmhub (e.g., Wordpress) will expose such details.

Relations are not direct connections between the workloads managed by the respective charms. Rather, a relation is a virtual connection between charms to allow the exchange of configuration information. The controller acts as a mediator for these virtual connections and manages the flow of information between the charms.

Relations may be formed between applications that run in different Juju models. To learn more, see cross-model relations

Last updated a month ago.