Use juju 3 5 1

[hmlanigan]

Description

Fixing the issue reported in #475 by pulling in the newer juju api versions. Will be validated by @babakks during RC.

Testing the provider with juju 3.5.1 APIs, found a bug in our provider configuration code where juju login details are discovered. Both client ID/secret and username/password were being provided to the juju client. These represent the 2 methods for juju login possible, however only 1 may be used at any time. The former method is for JIMM and the latter is used for directly juju login. Client ID/Secret can be found either in the plan and/or specific environment variables. Username/password can be found the same way and via discovery by using the juju cli.

Use the terraform plan is the principal definition of the juju login details for the provider. If pieces are missing, attempt to find them from the specific environment variables. At this point if the Client ID/Secret method is being used, all pieces are required, or we error. If username/password are being used and all pieces are not available, attempt discovery via the juju cli.

Directly use only 1 version of a package, in this case the juju/charm package.

Type of change

• Other (please describe)

QA steps

All current integration tests are successful.

Scenarios depend on specific controller used for test. The test scenarios below will contain a framework for tests, you must add your controller details. It's recommended to put the certificate in a file.

All potential information for juju login inside of a plan is listed below. Using all should fail with a message indicating the problem.

provider "juju" {
  controller_addresses = <controller-ip-addrs>
  username = "admin"
  password = <password>
  ca_certificate = file("./controller.pem")
  client_id = "testme"
  client_secret = "secret"
}

Possible environment variables are as follows:

JUJU_CONTROLLER_ADDRESSES
JUJU_USERNAME
JUJU_PASSWORD
JUJU_CA_CERT
JUJU_CLIENT_ID
JUJU_CLIENT_SECRET

Unless you have a JIMM config, using the client ID/secret method won't succeed. However it'll be an juju error message, not directly from the terraform provider.

Please test combinations of the 3 methods to provide juju login for configuration within the limited described. An informative error message should appear when the correct details are not available.

Additional notes

https://warthogs.atlassian.net/browse/JUJU-6156

[cderici]

I'm trying a bunch of combinations of uses, and I might've caught something.

So, using all in the plan causes the schema validation to yell, so that's expected.

Using all from the environment variables; the client credentials take precedence and I get the Juju error (because I don't have a jimm setup), I suppose that's also expected. (I'm not %100 on this since the QA says Using all should fail with a message indicating the problem, not sure if it's just for using the plan).

However, if I set the JUJU_CLIENT_ID and the JUJU_CLIENT_SECRET vars, and have the username and the password from the plan, then it seems to be working (with the username and password). I'm not entirely sure if this is expected behavior since I'm not getting any errors. Here's the setup:

 $ echo $JUJU_PASSWORD

 $ echo $JUJU_USERNAME

 $ echo $JUJU_CLIENT_ID
testme
 $ echo $JUJU_CLIENT_SECRET
secret

and in the plan:

provider "juju" {
  controller_addresses = "10.95.232.124:17070"
  ca_certificate = file("./controller.pem")

  username = "admin"
  password = "e0f6051527a2d17a1be099492356933c"
  
  // client_id = "testme"
  // client_secret = "secret"
}

and it works:

$ terraform apply --auto-approve

Terraform used the selected providers to generate the following execution plan. Resource
actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # juju_application.a will be created
  + resource "juju_application" "a" {
      + constraints = (known after apply)
      + id          = (known after apply)
      + model       = "tst"
      + name        = "a"
      + placement   = (known after apply)
      + principal   = (known after apply)
      + trust       = false
      + units       = 1

      + charm {
          + base     = "[email protected]"
          + channel  = (known after apply)
          + name     = "juju-qa-dummy-sink"
          + revision = (known after apply)
          + series   = (known after apply)
        }
    }

Plan: 1 to add, 0 to change, 0 to destroy.
juju_application.a: Creating...
juju_application.a: Creation complete after 1s [id=tst:a]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

[babakks]

Thanks for this PR. I just noticed one potential issue.

[hmlanigan]

@cderici

However, if I set the JUJU_CLIENT_ID and the JUJU_CLIENT_SECRET vars, and have the username and the password from the plan, then it seems to be working (with the username and password). I'm not entirely sure if this is expected behavior since I'm not getting any errors.

This is expected. If all the info necessary is in the plan, we check no where else.

The environment variables are only checked if not all data necessary to connect to the controller is available in the plan.

[cderici]

Good to go 👍