_This issue was originally opened by @henrikhodne as hashicorp/terraform#8176. It was migrated here as part of the provider split. The original body of the issue is below._
I managed to get in a state where the startup script for some of our GCE instances got updated, but the Terraform state didn't get the new startup scripts. Now Terraform wants to recreate all the instances since it thinks the instances still have the old startup script.
While browsing the code I found this: https://github.com/hashicorp/terraform/blob/8f976e5ceb3a229a9602fed93b536635bc661086/builtin/providers/google/resource_compute_instance.go#L620-L622
if script, scriptExists := d.GetOk("metadata_startup_script"); scriptExists {
d.Set("metadata_startup_script", script)
}
Looks to me like that's effectively a no-op, and should've pulled the script from the API response, not the state?
$ terraform -v
Terraform v0.7.0
resource "google_compute_instance" "some_server" {
name = "some_server"
machine_type = "g1-small"
zone = "us-central1-b"
can_ip_forward = false
disk {
auto_delete = true
image = "${var.image}"
type = "pd-ssd"
}
network_interface {
network = "default"
access_config {
# Ephemeral IP
}
}
metadata_startup_script = "#!/usr/bin/env bash\ndo_some_things"
}
terraform refresh updates the local state with the startup script that is visible in the GCE API.
terraform refresh keeps the startup script that is in the local state, and terraform plan says that the instance needs to be recreated.
terraform applyterraform planI got in this state because terraform apply didn't update the local state after applying, possibly because I managed to name the plan files something.tfstate instead of something.tfplan and ran terraform.tfstate? I can send a different ticket for that, though.
Issue still present in 0.9.8.
In the instance schema, metadata_startup_script is marked as ForceNew: true. Seems like since it's just a metadata value, it shouldn't require recreation.
I think that ForceNew makes sense in this context, because that way instances get recreated and then run the new startup script when we modify the value in our .tf configuration file.
Ideally, I'd like to see it being read in on every read - that way we can update the value when it was not initially set in schema, or when we perform an import. This might cause diffs (and recreates) for clients that previously relied on the value not being read back, but we'll fix this issue where the configuration has been updated and the upstream value has been too, but we don't read it back in.
Spoke to @rileykarson out-of-band; I think after discussion we agreed it should probably not be ForceNew (correct me if I'm wrong Riley).
Also, the pointed code snipped indeed looks like a no-op.
Actually, maybe it SHOULD be ForceNew, at least according to the documentation:
metadata_startup_script - (Optional) An alternative to using the startup-script metadata key, except this one forces the instance to be recreated (thus re-running the script) if it is changed. This replaces the startup-script metadata key on the created instance and thus the two mechanisms are not allowed to be used simultaneously.
Perhaps this behavior is intended? Looks like it was documented intentionally in 9fa642cee76fa689c3a860d876025efe429936b8 and added in a4037a0f61d11ae4752daae5ef3114a663acfc39
Closed with #180.
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 👉 [email protected]. Thanks!
Most helpful comment
Spoke to @rileykarson out-of-band; I think after discussion we agreed it should probably not be
ForceNew(correct me if I'm wrong Riley).Also, the pointed code snipped indeed looks like a no-op.