juju_integration (Resource)¶

A resource that represents a Juju Integration.

Example Usage¶

resource "juju_integration" "this" {
  model = juju_model.development.name
  via   = "10.0.0.0/24,10.0.1.0/24"

  application {
    name     = juju_application.wordpress.name
    endpoint = "db"
  }

  application {
    name     = juju_application.percona-cluster.name
    endpoint = "server"
  }

  # Add any RequiresReplace schema attributes of
  # an application in this integration to ensure
  # it is recreated if one of the applications
  # is Destroyed and Recreated by terraform. E.G.:
  lifecycle {
    replace_triggered_by = [
      juju_application.wordpress.name,
      juju_application.wordpress.model,
      juju_application.wordpress.constraints,
      juju_application.wordpress.placement,
      juju_application.wordpress.charm.name,
      juju_application.percona-cluster.name,
      juju_application.percona-cluster.model,
      juju_application.percona-cluster.constraints,
      juju_application.percona-cluster.placement,
      juju_application.percona-cluster.charm.name,
    ]
  }
}

Schema¶

Required¶

model (String) The name of the model to operate in.

Optional¶

application (Block Set) The two applications to integrate. (see below for nested schema)
via (String) A comma separated list of CIDRs for outbound traffic.

Read-Only¶

id (String) The ID of this resource.

Nested Schema for `application`¶

Optional:

endpoint (String) The endpoint name. This attribute may not be used at the same time as the offer_url.
name (String) The name of the application. This attribute may not be used at the same time as the offer_url.
offer_url (String) The URL of a remote application. This attribute may not be used at the same time as name and endpoint.

Notes¶

When creating this resource the offer_url property will show (known after apply) if a name or name and endpoint are supplied as below:

  + resource "juju_integration" "this" {
      + id    = (known after apply)
      + model = "this"
      + via   = "10.0.0.0/24,10.0.1.0/24"

      + application {
          + endpoint  = (known after apply)
          + name      = "one"
          + offer_url = (known after apply)
        }
    }

This is due to an integration requiring a name/endpoint combination or an offer_url, but not both bits of data together.

Cross-model relations¶

From v0.23, when integrating with an offer (i.e. when specifying the offer_url), the provider will create a remote application name with the format <remote-app>-<local-app>-<interface>. For example, when relating a local application called discourse with an offer url of the form admin/dbModel.postgresql, using the database interface, the remote application will have the name postgresql-discourse-database.

In previous versions of the provider, the remote application would always have the same name as the application in the offer url, i.e. postgresql in the example above.

This ensures that local applications have a 1:1 relation with remote applications.

This change is backwards compatible and existing integrations will continue to work. However, take care when destroying integrations created by previous versions of the provider. If two apps relate the same remote application (e.g. if the offer provides multiple endpoints or two apps rely on the same offer/endpoint) and one of the integrations is removed, the other will also be affected.

Before v0.23:

        flowchart LR
    A[App A] -->|Integrate| C(Remote APP)
    B[App B] -->|Integrate| C
    C -->|Cross Model| D[Offer]
    D--> E[App C]

After v0.23:

        flowchart LR
    A[App A] -->|Integrate| C(Remote App 1)
    B[App B] -->|Integrate| D(Remote App 2)
    C -->|Cross Model| E[Offer]
    D -->|Cross Model| E[Offer]
    E--> F[App C]

Import¶

Import is supported using the following syntax:

# Integrations can be imported by using the format: model_name:provider_app_name:endpoint:requirer_app_name:endpoint.
# For integrations with an offer url, replace the requirer_app_name with the remote application name. The remote app
# name can be found by running `juju status` and looking for the SAAS heading.
# For example:
$ terraform import juju_integration.wordpress_db development:percona-cluster:server:wordpress:db