DigitalOcean volume - prevent deletion (detach only) on destroy

[ksanderer]

Is it possible somehow to prevent DO volume deletion on terraform destroy (or any other action that may force to delete the volume - resize, etc..)?

It will be awesome to have DO volume attribute detach_only = true/false to be sure that persistent volume with sensitive data can't be deleted with other infrastructure.

resource "digitalocean_volume" "foobar" {
  region      = "nyc1"
  name        = "baz"
  size        = 100
  description = "an example volume"
  detach_only = true
}

I think this behavior would be useful for other cloud providers as well (aws, google, etc)

There is parameter lifecycle.prevent_destroy, but it's just bloks the operation and not really useful for that kind of workflows.

[japsen]

Having this would have saved me many hours of manual work.

[ksanderer]

@japsen I've achieved such functionality by encapsulating persistent infrastructure in separate terraform project. It looks like this:

1. Create teraform project with persistant objects, describe volumes and add them to the output.tf
2. In the main terraform project:

// -----------------------------------------------
// External persistent state (volumes, ssh_keys, etc)
// -----------------------------------------------

data "terraform_remote_state" "persistent" {
  backend = "local"

  config {
    path = "${path.cwd}/persistent/terraform.tfstate"
  }
}

Now you can reach volumes from the external terraform state like this:

${data.terraform_remote_state.persistent.do_ssh_key}

And they can't be affected by any operation in the main terraform project.

[japsen]

@ksanderer wow, that's a great solution. Way better than creating volumes manually and fetching their id's via the DO API. I Will definitely implement it when deploying a new project if the 'detach_only' option is not available yet by then.

[ap1969]

@ksanderer Thanks for sharing the solution. This is a great idea, and can be used in lots of other situations as well. Appreciate your advice.

[danielsreichenbach]

This seems to be the perfect use case for using distinct environments to deploy pieces of infrastructure that should have only immutable access to other resources.

This talk describes the concepts quite nicely.