Integration
See also:
Before juju v.3.0 , integrations were called ‘relations’. The ‘relation’ terminology is still around in commands such as remove-relation or options such as juju status --relations.
In Juju, an integration is a protocol facilitated by Juju that allows applications to auto-negotiate their configuration. An application’s integrations are defined by its charm and formed by connecting the application’s 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 integrations set up between both MySQL and Apache (a potential integration 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 integration 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.
Integrations are not direct connections between the workloads managed by the respective charms. Rather, an integration 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.
Integrations may be formed between applications that run in different Juju models. To learn more, see cross-model integrations.
Last updated 7 months ago.