Call for testing: The Juju Terraform provider v2.3.0-rc1

announcements and community
1

Juju Terraform provider 2.3.0-rc1 release notes

26 August 2026

:puzzle_piece: Requirements and compatibility

  • This release requires a Juju controller of version 3.6 or higher. Support for Juju 2.9 controllers is not available in the v2 track; 2.9 continues to be supported on the v1 track for security updates and bug fixes.
  • If you are using JAAS, this release requires a Juju controller of version 3.6.5 or higher. Cloud management through JAAS (new in this release) additionally requires JAAS v3.4.4 or higher.
  • This release builds against the Juju client API code from the latest Juju development branch, and is compatible with both Juju 3 and Juju 4 controllers.

:rocket: New features

Plan without a live controller

The provider gains a lazy_api_check flag that skips connecting to the Juju controller while planning the creation of resources. Until now, even terraform plan required a reachable controller, which made it impossible to compose plans in which the controller itself is created earlier in the same run — a common pattern with tools such as Terragrunt stacks. With lazy_api_check = true, plans for new resources succeed without a controller, and connection or validation errors surface at apply time instead. Note that the provider still connects to the controller when planning updates, and that validators/checks that normally run at plan time (relevant for some JAAS-only resources) are deferred to apply time.

  • Add lazy_api_check flag to enable planning without a real controller by @SimoneDutto in #1324.

    provider "juju" {
  lazy_api_check = true
}

Provider-level default timeouts

Wait timeouts used to be hard-coded (30 minutes for create/update, 15 minutes for delete) with no way to configure them. The provider now accepts a default_timeouts block that applies to all resources, with precedence: resource-level timeouts block first, then the provider default_timeouts, then the built-in defaults. Omitting the block keeps the previous behaviour. As part of the same change, the juju_application resource gains a per-resource timeouts block (create), alongside the existing ones on juju_machine and juju_offer.

  • Add provider-level default timeouts by @luci1900 in #1337.

    provider "juju" {
  default_timeouts {
    create = "60m"
    update = "45m"
    delete = "20m"
    read   = "10m"
  }
}

Wait for machine IP addresses

The juju_machine data source gains a wait_for_ip_addresses field: a list of IP address conditions the provider waits for before completing the read. Each element is either a CIDR (for example "10.0.10.0/24") or one of the aliases "public", "private", or "any". The matching addresses are populated in the computed ip_addresses field, in the same order as the conditions. This makes it possible to hold a plan until a machine has obtained an address on a specific subnet — for example on a secondary NIC — and then pass that address to other resources.

  • Add wait_for_ip_addresses machine data source by @SimoneDutto in #1323.

    data "juju_machine" "this" {
  model_uuid            = juju_model.this.uuid
  machine_id            = juju_machine.this.machine_id
  wait_for_ip_addresses = ["10.20.30.0/24", "any"]
}

output "machine_ip" {
  value = data.juju_machine.this.ip_addresses
}

Cloud management through JAAS

Following the release of JAAS v3.4.4, clouds can now be fully managed through a JAAS controller: the juju_kubernetes_cloud resource supports updates against JAAS, and cloud add/update/destroy operations are available for all cloud types.

  • Allow JAAS to update Kubernetes Cloud and all clouds CRUD by @SimoneDutto in #1338.

Machine instance IDs

The cloud provider instance ID of a machine is now exposed as a computed instance_id field on both the juju_machine resource and the juju_machine data source, making it available to reference from other resources (for example, cloud-provider resources that attach to the underlying instance).

  • Add instance_id field to juju_machine resource by @alexdlukens-canonical in #1325.
  • Add instance_id field to juju_machine data object by @alexdlukens-canonical in #1340.

:hammer_and_wrench: Bug fixes

  • Resource IDs are persisted immediately after creation — previously, if a resource was created successfully but the provider then failed while waiting for it to become ready, the resource’s ID was not recorded in the Terraform state, leaving the deployed resource unmanaged. The ID is now persisted as soon as the resource is created, so a failure in a subsequent wait marks the resource as tainted and it is recreated on the next terraform apply. Persist resource ID after creation by @SimoneDutto in #1334 (addresses #1333).

:broom: Maintenance

:raising_hands: New contributors

  • @alexdlukens-canonical made their first contribution in #1325.

Full changelog: https://github.com/juju/terraform-provider-juju/compare/v2.2.1...v2.3.0