Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request juju#17309 from babakks/css-8360/apply-client-in-s…
…imple-connector juju#17309 **(Note that this PR is relevant to JIMM controllers which support login with client credentials. So whenever we say *controller*, it's a *JIMM controller*.)** When Juju Terraform Provider uses client credentials (as a service account) to communicate with the API using a `SimpleConnector`, it leaves `SimpleConfig.Username` empty and assigns the client credentials to `SimpleConfig.ClientID` and `SimpleConfig.ClientSecret`. The problem is the `NewSimple` function does not take this into account and panics with the following message whenever the `Username` is empty: ``` invalid user tag "" ``` This PR adds a simple check to prevent the panic. ## Checklist <!-- If an item is not applicable, use `~strikethrough~`. --> - [x] Code style: imports ordered, good names, simple structure, etc - [x] Comments saying why design decisions were made - [ ] ~Go unit tests, with comments saying what you're testing~ - [ ] ~[Integration tests](https://github.com/juju/juju/tree/main/tests), with comments saying what you're testing~ - [ ] ~[doc.go](https://discourse.charmhub.io/t/readme-in-packages/451) added or updated in changed packages~ ## QA steps QA-ing this change is a bit complicated because of two reasons: 1. The `NewSimple` function is meant to be used by users of the `juju/juju` module, and hence there's no internal usage in Juju (so we can verify the changes without spinning up other things). To invoke the method, we can use Juju Terraform Provider. Note that, for this purpose, we need to build the provider with the new Juju changes. 2. We'd need a controller that provides the newly introduced login method, `LoginWithClientCredentials`. If the controller The only controller that supports this method at the moment, is JIMM. Therefore, we need to spin up a JIMM controller. If we try with a non-JIMM controller, instead of a panic we get this error, which is a bit misleading but converts the unsupported state: ``` this version of Juju does not support login from old clients (not supported) (not supported) ``` We can, of course, help out with QA-ing this to make sure it works as expected. Anyway, the whole QA process should look like this: 0. Build the Juju Terraform Provider with the changes in Juju. 1. Spin up a JIMM controller. 2. Create a Terraform plan from this template: ```tf terraform { required_providers { juju = { source = "registry.terraform.io/juju/juju" # (uses local provider repository) version = "=0.12.0" } } } provider "juju" { controller_addresses = "jimm.localhost:443" client_id = "some-client-id" # Value not important client_secret = "some-secret" # Value not important ca_certificate = <<EOT -----BEGIN CERTIFICATE----- JIMM TLS termination CERT -----END CERTIFICATE----- EOT } resource "juju_model" "qa" { name = "qa" cloud { name = "localhost" } } resource "juju_application" "qa" { name = "qa" model = juju_model.qa.name charm { name = "juju-qa-test" } units = 1 } ``` 3. Run `terraform init` and `terraform apply`. 4. No Panic (i.e., `invalid user tag ""`) should happen. ## Documentation changes <!-- How it affects user workflow (CLI or API). --> ## Links <!-- Link to all relevant specification, documentation, bug, issue or JIRA card. --> **Launchpad bug:** https://bugs.launchpad.net/juju/+bug/ **Jira card:** JUJU-
- Loading branch information