# juju_integration (Resource)

A resource that represents a Juju Integration.

## Example Usage

```terraform
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 generated by tfplugindocs -->

## 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.

<a id="nestedblock--application"></a>

### 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.
- `offering_controller` (String) The name of the offering controller where the remote application is hosted. This is required when using offer_url to consume an offer from a different controller.

### 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:

```default
  + 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](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:

v0.23.0:

v0.23.1:
Same as before v0.23.0.

## Import

Import is supported using the following syntax:

```shell
# 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
```

Alternatively, it’s possible to use the `import` block in your plan. For example:

```tf
import {
  to = juju_integration.this
  id = "${data.juju_model.development.uuid}:percona-cluster:server:wordpress:db"
}
```

### Cross-controller integration import

It’s also possible to import an integration between models on different controllers. For example:

```tf
provider "juju" {
  # In addition to the default controller, configure the offering one
  offering_controllers = {
    "db-controller" = {
      controller_addresses = "..."
      username             = "..."
      password             = "..."
      ca_certificate       = "..."
    }
  }
}
resource "juju_integration" "this" {
  model_uuid = juju_model.development.uuid
  via        = "10.0.0.0/24,10.0.1.0/24"
  application {
    # Controller name must match the name set up in the `provider`s `offering_controllers` block
    offering_controller = "db-controller"
    offer_url           = "owner/db-model.db"
    endpoint            = "db"
  }
  application {
    name     = juju_application.percona-cluster.name
    endpoint = "server"
  }
}
import {
  to = juju_integration.this
  # UUID obtained through a data source
  id = "${data.juju_model.development.uuid}:percona-cluster:server:wordpress:db"
}
```

To verify that you’ll get the result you want, check the output of terraform plan – it should
show resources being imported and none destroyed and recreated. For example:

```shell
Terraform will perform the following actions:

  # juju_integration.sink-source will be imported
    resource "juju_integration" "db" {
        id         = "...:percona-cluster:server:wordpress:db"
        model_uuid = "..."

        application {
            endpoint            = "db"
            offer_url           = "owner/db-model.db"
            offering_controller = "db-controller"
        }
        application {
            endpoint = "source"
            name     = "server"
        }
    }

Plan: 1 to import, 0 to add, 0 to change, 0 to destroy.
```