google_compute_instance additional_disk support autoDelete

steven-edgar commented 5 years ago

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 the 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 the issue is assigned to a user, that user is claiming responsibility for the issue. If the issue is assigned to "hashibot", a community member has claimed the issue already.

Description

google_compute_instance_template is missing a parameter for the attached_disk block. The GCP API for compute instances attach_disk supports the autoDelete flag. This flag causes the disk to be automatically deleted when the instance is deleted. This is useful for situations where the instances might be deleted manually, or via processes not using Terraform.

New or Affected Resource(s)

google_compute_instance

Potential Terraform Configuration

resource "google_compute_instance" "my-vm-1" {
  name              = "my-vm-1"
  machine_type = "n1-standard-1"
  .....
  attached_disk {
    source           = "my-second-disk"
    device_name = "disk2"
    auto_delete   = true
  }
  ....
}

References

Chupaka commented 5 years ago

In "situations where the instances might be deleted manually, or via processes not using Terraform" you don't use Terraform :)

emilymye commented 5 years ago

In the past we have intentionally not supported this (see https://github.com/terraform-providers/terraform-provider-google/issues/539) - I'll repeat the question posed by Dana in that thread:

this was an intentional omission, since deleting the disk server-side when the instance goes away means your terraform state won't be consistent (since the disk you used to attach it will still be in state). Can I ask what your use case is?

If your use case is indeed only for situations where the instance has changed outside of Terraform, I'm afraidthis is just a situation where we had to choose which state inconsistency we want to deal with. While it might work ok if your disk isn't in state, often users do have disk in state and auto-delete would make state management more complicated or cause unexpected behavior.

steven-edgar commented 5 years ago

Thanks for the reply. Reflecting on it I think I see your point, if Terraform were told to remove the instance, but not the disks, and auto-delete were enabled, then it would not specifically delete the disks, but they would still be deleted by GCP. This behaviour would not be shown in a plan run, and so could lead to unwanted outcomes, as well as the state still showing the disks existing.

I would point out that google_compute_instance_template does support auto-delete for disks, and if those disks are attached using "source" rather than "source_image" then surely the same argument exists? It would appear inconsistent to support this in compute instance template but not compute instance. I'm assuming here that the documentation for compute instance template is consistent with the code.

I wonder if it is not possible to support auto-delete without the state issues. For example;

When auto-delete is enabled for an attached disk, terraform could match that disk (if a google_compute_disk lookup is used for the source field of that attached disk) to the terraform resource, thereby causing terraform to delete the disk from the state at the same time as the compute instance. This would also need to show up as removing the disk when a destroy-plan is run. This would be similar to having a depends_on entry for the disk pointing at the compute instance, but without the circular issue when provisioning. Auto-delete would only be supported when source is a lookup, otherwise throwing an error.

mmiller1 commented 2 years ago

We've run into instances where a VM may fail in the provisioning stages, and a reconverge will delete the VM and retry - we also expect to be able to have a blank disk in order for provisioning to succeed, so either an option in Terraform to specifically delete any attached disks during recreate, or using the auto delete functions in the GCP APIs would be very helpful.

kxs581 commented 2 years ago

I am facing the same issue with the autoDelete = false option using in additional_disks with source as a regional disk. When i am trying terraform destroy along with the instance the regional disk is also getting deleted which should not in normal case. Was there any work around for this issue please

rileykarson commented 1 year ago

Note: I think we implemented auto_delete in some form on another resource (possibly disk or instance template?). We should consider using that as a precedent for this.

hashicorp / terraform-provider-google