[JUJU-3315] Force "stable" channel to be "latest/stable" when reading apps.

[juanmanuel-tirado]

Description

Depending on how a charm is uploaded to CharmHub, Juju may resolve the channel to be stable instead of latest/stable. This leads to awkward situations where Terraform things the state has changed as reported in #113. This PR forces the stable channel to be replaced by latest/stable when reading applications.

Fix #113.

Type of change

Please mark if proceeds.

• New resource (a new resource in the schema)
• Changed resource (changes in an existing resource)
• Logic changes in resources (the API interaction with Juju has been changed)
• Test changes (one or several tests have been changed)
• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update
• Other (describe)

Environment

• Juju controller version: 2.9.42
• Terraform version: 1.4.6

QA steps

The steps reported in #113 are no longer valid to reproduce this issue after the last changes in the postgresql-k8s charm. A similar scenario can be reproduced using the github-runner charm.

Deploy the github-runner charm

juju bootstrap microk8s datest
juju add-model ghrunner
juju deploy github-runner ghrunner

Create a plan and import the model and the application

terraform {
  required_providers {
    juju = {
      source  = "juju/juju"
      version = "1.0.0"
    }
  }
}

provider "juju" {}

resource "juju_model" "ghrunner" {
  name = "ghrunnertest"
}

resource "juju_application" "ghrunner" {
  name  = "ghrunner"
  model = juju_model.ghrunner.name

  charm {
    name = "github-runner"
  }

  units = 1
}

terraform init -plugin-dir=<wherever your compiled providers are>
terraform import juju_model.ghrunner ghrunner
terraform import terraform import juju_application.ghrunner ghrunner:ghrunner

Terraform should not detect any changes

terraform plan

juju_model.ghrunner: Refreshing state... [id=08552cd9-4e03-40d5-8a3a-3d6f09faee7f]
juju_application.ghrunner: Refreshing state... [id=ghrunner:ghrunner]

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

If the same steps are done with the 0.6.0 controller, Terraform finds changes to be done.

terraform plan
juju_model.ghrunner: Refreshing state... [id=08552cd9-4e03-40d5-8a3a-3d6f09faee7f]
juju_application.ghrunner: Refreshing state... [id=ghrunner:ghrunner]

Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # juju_application.ghrunner will be updated in-place
  ~ resource "juju_application" "ghrunner" {
        id          = "ghrunner:ghrunner"
        name        = "ghrunner"
        # (5 unchanged attributes hidden)

      ~ charm {
          ~ channel  = "stable" -> "latest/stable"
            name     = "github-runner"
            # (2 unchanged attributes hidden)
        }
    }

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

[cderici]

This seems incorrect. We shouldn't need to coerce the track in the client. The app is deployed with the channel stable and ReadApplication (applicationAPIClient.ApplicationsInfo really) is correctly bringing the channel as stable. I think the problem is we incorrectly default to latest/stable when a channel is not specified. I believe the correct fix is defaulting to just stable instead of fixating the track as well.

[juanmanuel-tirado]

I gave it a second thought. I think this approach makes more sense. We will make the channel field to be computed so the value is decided during the deployment phase. If by the time we create an application the channel is empty, we will force it to be stable.

[cderici]

Yeah I think this is correct 👍 we should probably remove that defaulting to the latest/stable at some point as well.