I have a google_compute_target_https_proxy with an SSL certificate that I've uploaded manually to Google Cloud Console. It looks something like this:
resource "google_compute_target_https_proxy" "my-target-https-proxy" {
name = "my-lb-target"
url_map = "${google_compute_url_map.my-target-url-map.self_link}"
ssl_certificates = ["projects/my-${var.my_environment_name}/global/sslCertificates/app-myapp-com"]
}
When I plan and apply this resource, my target https proxy is created exactly as I'd expect. There's a proxy with the SSL cert that I had previously uploaded. Yay.
However, when I run terraform plan, it shows that the this resource is dirty and needs to be recreated:
~ google_compute_target_https_proxy.my-target-https-proxy
ssl_certificates.#: "0" => "1"
ssl_certificates.0: "" => "projects/my-staging/global/sslCertificates/app-myapp-com"
This is very odd, as the target https proxy is still configured perfectly accordingly to my google cloud console. I'm not sure why terraform is refreshing my state incorrectly here. Is this a bug?
Thanks for the input!
I found a workaround. I added a line to my google_compute_target_https_proxy:
lifecycle {
ignore_chnages = ["ssl_certificates"]
}
This seems to do the trick for me. Is this a good thing to do?
Reopening this because it does indeed look like a bug. This sort of behavior is usually a bug in the resource's Read implementation, incorrectly mapping what was returned from the API into the resource attributes.
Thanks for the quick reply!
After the initial terraform apply, the state file still shows "ssl_certificates.#": "0"
Running terraform apply again returns an api error that there is already 1 cert on the resource, and you can't have 2.
terraform refresh does not bring the state file to the correct state, as I've seen it do with other issues like this.
I face the same issue. Any chance this will be fixed soon ?
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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Most helpful comment
Reopening this because it does indeed look like a bug. This sort of behavior is usually a bug in the resource's
Readimplementation, incorrectly mapping what was returned from the API into the resource attributes.