juju_integration (Resource)¶

A resource that represents a Juju Integration.

Example Usage¶

resource "juju_integration" "this" {
  model_uuid = juju_model.development.uuid
  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_uuid (String) The UUID 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¶

Version 0.23.0 of the provider introduced a change 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.

While change is backwards compatible, it uncovered a Juju bug that will cause an issue when relating to the same offer multiple times, see https://github.com/juju/juju/issues/20818 for more details. For this reason, the change is being reverted in v0.23.1 of the provider.

While deployments made using v0.23.0 will continue to work, you may have noticed saas applications with the name <remote-app>-<local-app>-<interface>. After upgrading to v0.23.1, these apps will continue to exist and work as expected but newly consumed offers will follow the previous naming convention.

See the diagrams below for a comparison of the changes.

Before v0.23.0:

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

v0.23.0:

        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]

v0.23.1: Same as before v0.23.0.

Import¶

Import is supported using the following syntax:

# Integrations can be imported by using the format: model_uuid: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 4b6bd192-13bb-489d-b7a7-06f6efc2928d:percona-cluster:server:wordpress:db