Upcoming changes in the Juju Terraform provider

The Juju team is happy to announce some changes for the Juju Terraform provider

In the past month, we have been thinking about the future of the Juju Terraform provider and have now decided to share some of the upcoming changes for the v1.0.0 release currently scheduled for October and others that will likely come after that date.

We invite all those interested in the Juju Terraform provider to read through this post and linked specifications and let us know your thoughts, especially if what is described covers your use cases.

Replacing model name with model UUID

In the current version of the Juju Terraform provider, users had to refer to models using model names. Example:

resource "juju_model" "development" {
  name = "development"
}

resource "juju_application" "this" {
  name = "my-application"

  model = juju_model.development.name
}

In v1.0.0 we will deprecate the use of model names in favor of model UUIDs in Terraform plans. The above example will look like:

resource "juju_model" "development" {
  name = "development"
}

resource "juju_application" "this" {
  name = "my-application"

  model = juju_model.development.uuid
}

The purpose of this change is to uniquely identify a model. In Juju, a model is uniquely identified either by its UUID or by its full name, which is <model owner>/<model name>. Today, each user may have their own development model, each in their own “namespace”. But the Juju Terraform provider has a subtle bug in that it only accounts for the model name. If there were multiple models with the same name, but different owners in a Juju controller, the Terraform provider might have issues correctly identifying the right model. With the use of JAAS and multiple controllers, we expect users will start facing this issue in the near future.

Full details of this change are described in this issue.

Bootstrapping Juju controllers

Following the v1.0.0 release, we will be adding a juju_controller resource to the Juju Terraform provider, which will enable users to bootstrap new Juju controllers. Example:

resource "juju_controller" "new_controller_1" {
name = "test-controller"


cloud = {}


credentials = “<cloud credential>”


agent_version = "<agent version>"
bootstrap_base = "<base of the bootstrap machine>"
bootstrap_series = "<series of the bootstrap machine>"
bootstrap_constraints = "<bootstrap machine constraints>"
config = {}
model_constraints = {}


output_file = “<path to the output file>”
}

Full details are described in this issue.

Proposal for juju actions

After much popular demand, we propose the introduction of the juju_action resource. Example:

resource "juju_action" "action" {
  model_name        = juju_model.model1.name
  application_name  = juju_application.app1.name
  action_name       = "<action_name>"

  unit = "<unit_number>"
  args = {
    "arg1" = "val1"
  }
}

@simonedutto created a PoC and owns the github issue with full details.

This feature will also be introduced after the v1.0.0 release.

Hi all,

I amended the above post with correct links to github issues.

Apologies, Ales