google_iap_brand does not work

[minac]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave +1 or me too comments, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.
• If an issue is assigned to the modular-magician user, it is either in the process of being autogenerated or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

Terraform v0.12.24

• provider.google v3.16.0
• provider.google-beta v3.16.0

Affected Resource(s)

• google_iap_brand

There is no data source yet.

Terraform Configuration Files

provider "google" {
  credentials = file("my-credentials.json")
  project     = "my-project"
  region      = "us-central1"
  zone        = "us-central1-c"
}

provider "google-beta" {
  credentials = file("my-credentials.json")
  project     = "my-project"
  region      = "us-central1"
  zone        = "us-central1-c"
}
data "google_project" "project" {
}

resource "google_project_service" "project_service" {
  project = data.google_project.project.project_id
  service = "iap.googleapis.com"
}

resource "google_iap_brand" "default" {
  provider          = google-beta
  application_title = "Cloud IAP protected Application"
  project           = "my-project"
  support_email     = "myemail@example.com"
}

Debug Output

https://gist.github.com/minac/3eca9d579f501beda7e4507471ef5be0

Panic Output

N/A

Expected Behavior

The IAP brand would either be created or accept the existing one and move on.

Actual Behavior

The IAP brand was not marked created in the first run (although it was), and when I added the IAP client it attempts to create the brand and fails because it's already there.

Steps to Reproduce

1. terraform apply

Important Factoids

I tried this with a project that already had a brand created (which cannot be undone, even on Google console side). And then tried it with a fresh project with no brand created.

References

• #0000

[slevenick]

Hey @minac

Can you include debug logs for the run where terraform fails to create the brand when the project does not have a brand already?

The debug logs that you included are from a run where the brand already exists, and this fails in an expected way. When a specific resource already exists but terraform does not know about it, terraform will attempt to create it, which causes the 409 conflict failure.

You may want to import the existing brand rather than attempting to create it again: https://www.terraform.io/docs/import/index.html

[minac]

Hey Sam. I no longer have the debug session and logs, I’m afraid. The listing of operations showed the creation of all the other objects (like a GKE cluster), but not the brand. Then when I try to run again it says that the brand has already been created. The import fails as well. The docs mention a {{ name }} to import, but one must use the full project path. And then it fails to import in the same way as the creation. These two are simple to reproduce with what I sent. I hope this helps

On Tue, 14 Apr 2020 at 18:54, Sam Levenick ***@***.***> wrote: Hey @minac <https://github.com/minac> Can you include debug logs for the run where terraform fails to create the brand when the project does not have a brand already? The debug logs that you included are from a run where the brand already exists, and this fails in an expected way. When a specific resource already exists but terraform does not know about it, terraform will attempt to create it, which causes the 409 conflict failure. You may want to import the existing brand rather than attempting to create it again: https://www.terraform.io/docs/import/index.html — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6100 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGMVBVT4PRKQP6VWMVHUSDRMSPLTANCNFSM4MGMKQTA> .

-- Miguel David

[slevenick]

Hey Sam. I no longer have the debug session and logs, I’m afraid. The listing of operations showed the creation of all the other objects (like a GKE cluster), but not the brand. Then when I try to run again it says that the brand has already been created. The import fails as well. The docs mention a {{ name }} to import, but one must use the full project path. And then it fails to import in the same way as the creation. These two are simple to reproduce with what I sent. I hope this helps
On Tue, 14 Apr 2020 at 18:54, Sam Levenick @.***> wrote: Hey @minac https://github.com/minac Can you include debug logs for the run where terraform fails to create the brand when the project does not have a brand already? The debug logs that you included are from a run where the brand already exists, and this fails in an expected way. When a specific resource already exists but terraform does not know about it, terraform will attempt to create it, which causes the 409 conflict failure. You may want to import the existing brand rather than attempting to create it again: https://www.terraform.io/docs/import/index.html — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6100 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGMVBVT4PRKQP6VWMVHUSDRMSPLTANCNFSM4MGMKQTA .
-- Miguel David

Hmm, I'm able to import a brand. I'd note that the format of {{name}} is documented here: https://www.terraform.io/docs/providers/google/r/iap_brand.html#name

So the import command would look something like:
terraform import google_iap_brand.brand projects/{project}/brands/{project_number}

I would note that running terraform destroy causes terraform to think it destroyed the iap_brand, but it doesn't actually delete the brand because there is no support for deleting these resources from the API side. So after a successful create you will need to use import rather than trying to create a new brand in the future

[fbaier-fn]

Importing an existing brand (particular one that wasn't created by Terraform) succeeds, however I think this behavior makes a problem:

When a specific resource already exists but terraform does not know about it, terraform will attempt to create it, which causes the 409 conflict failure.

Let's say you want to change the support_email of an existing brand.

1. You import the brand

% terraform import google_iap_brand.existingbrand projects/myproject/brands/1234567890
google_iap_brand.existingbrand: Importing from ID "projects/myproject/brands/1234567890"...
google_iap_brand.existingbrand: Import prepared!
  Prepared google_iap_brand for import
google_iap_brand.existingbrand: Refreshing state... [id=projects/myproject/brands/1234567890]

Import successful!

The resources that were imported are shown above. These resources are now in
your Terraform state and will henceforth be managed by Terraform.

2. Run terraform plan just to see if there are any diffs (there shouldn't)

------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.

3. Make changes in your support_email field and apply:

Terraform will perform the following actions:

  # google_iap_brand.existingbrand must be replaced
-/+ resource "google_iap_brand" "existingbrand" {
        application_title = "retool"
      ~ id                = " projects/myproject/brands/1234567890" -> (known after apply)
      ~ name              = " projects/myproject/brands/1234567890" -> (known after apply)
      ~ org_internal_only = true -> (known after apply)
        project           = "myproject"
      ~ support_email     = "old@email.com" -> "new@email.com" # forces replacement

      - timeouts {}
    }

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

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

google_iap_brand.existingbrand: Destroying... [id= projects/myproject/brands/1234567890]
google_iap_brand.existingbrand Destruction complete after 0s
google_iap_brand.existingbrand: Creating...

Error: Error creating Brand: googleapi: Error 409: Requested entity already exists

  on ..iap.tf line 3, in resource "google_iap_brand" "existingbrand":
   3: resource "google_iap_brand" "existingbrand" {

This is getting the 409 like we saw in @minac 's debug output as well.

What's interesting to me here is, that Terraform works probably correct on the surface but runs into a limitation of the Google API. In particular

Note: Brands can be created only once for a Google Cloud Platform project and cannot be deleted. Destroying a Terraform-managed Brand will remove it from state but will not delete the resource on the server.

So whats interesting to me is, that it destroys rather than changing it in place. From the note above it is obvious that a destroy won't really destroy and then you run into the exact conflict that terraform ops out even before it creates/changes the resource because it is already there (conflict with 409).

Shouldn't we change the behavior here that changes to the object won't force replacement which leads us down to destroy/create and complain it exists?

[slevenick]

Ah, ok I see the issue. When the google_iap_brand resource is deleted it does not actually delete the brand in GCP. This is because there is currently no support for deleting or modifying the brand via the REST API: https://cloud.google.com/iap/docs/reference/rest/v1/projects.brands

Also see: https://cloud.google.com/iap/docs/programmatic-oauth-clients?#branding

Unfortunately this is not fixable via Terraform, although I will add a note to the brand resource about it being unable to be deleted.

If you want the ability to update and delete brands, feel free to file a feature request on the Identity-Aware proxy issue tracker here: https://cloud.google.com/support/docs/issue-trackers

[fbaier-fn]

Filed the feature request https://issuetracker.google.com/issues/154652489

[venkykuberan]

closing this issue as the work is the tracked in feature request.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!