-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
google_compute_instance network_ip selflink reference causes re-creation. #7841
Comments
Given the fact that the state only keeps the ip data instead of the reference, I am not sure if that is possible for not recreating the instance. I am not aware of any methods in the Terraform that can handle this |
Thanks for the reply! If that's the case, I might consider actively discouraging this practice. The detected mutation isn't the end of the world, but the main issue is that re-creating the instance can lead to downtime. I feel like it severely limits the scenarios where leveraging the selflink is useful, if this is the case. |
It's a little less dire than that! In many cases the API converts a reference to a canonical format (whether the self link format or the partial URI format) and the provider handles those. This is a little different. There's no way to tell if the returned IP corresponds to the provided self link. That leaves us with a few options:
resource "google_compute_address" "static" {
name = "internal-address"
}
data "google_compute_image" "debian_image" {
family = "debian-9"
project = "debian-cloud"
}
resource "google_compute_instance" "instance_with_network_ip" {
name = "vm-instance"
machine_type = "f1-micro"
zone = "us-central1-a"
boot_disk {
initialize_params {
image = data.google_compute_image.debian_image.self_link
}
}
network_interface {
network = "default"
network_ip = google_compute_address.static.address
}
} You could also use a datasource to fetch information about an address without managing it. I'm closing this out as both other approaches have strong downsides, and 3) works well today. |
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! |
Community Note
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 tohashibot
, a community member has claimed the issue already.Terraform Version
Affected Resource(s)
Terraform Configuration Files
Debug Output
https://gist.github.com/toumorokoshi/9646615be1173a522c432daba06a4a43
Expected Behavior
An apply with the exact same input values, that resolve to the exact same final values, should not force replacement.
Actual Behavior
When running apply on a google_compute_instance that is using a selflink value in network_interface.network_ip, re-running an apply results in a replacement of the whole compute_instance, as the selflink resolved to the actual IP address.
You can see the output of the TF plan here:
This happens after every apply.
Steps to Reproduce
terraform apply
Important Factoids
I believe there's actually a broad range of times when this issue occurs, but haven't investigated too deeply. Anytime a selfLink is used in this manner (replaced with a different string) with a field that requires replacement to be modified, there will be an unneeded forced replacement.
Another one worth looking into is
boot_disk.initialize_params.image
, which expands families of images into the fully qualified name.References
The text was updated successfully, but these errors were encountered: