search

hashicorp / terraform

Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
https://www.terraform.io/
Other
42.37k stars 9.49k forks source link

Persistent Resources #20065

Open edward2a opened 5 years ago

edward2a commented 5 years ago

This is a quite simple idea.

A resource marked 'persistent = "true"' will have its destroy action skipped, and a terraform destroy operation will succeed without removing this resource or it's state.

A flag is to be added to the destroy operation with the name of '-include-persistent' or something as indicative like that, i.e. '-destroy-persistent', to allow a full destroy operation of the whole set.

This works for multiple things like:

tdmalone commented 5 years ago

Interesting idea! I would imagine in practice that this might work similar to resources such as aws_default_vpc (which, by design, can’t be destroyed - although it doesn’t support a ‘force’ destroy and it does remove from state).

edward2a commented 5 years ago

This also ties with a situation I have with vault where I want TF to create/update secrets but not to be able to delete these.

vincbe commented 5 years ago

In our case, we'd like to use a shared PubSub topic for different GCP/GKE application instances. It looks like it would be so practical to have it like a resource to create if not existing but to never destroy. For the moment we are thinking about managing this specific topic independently (its also make sense but less ready to use as a whole) or to define the topic as a null_resource with a command to create and just a message when destroying. We could have this kind of needs for storage buckets too.

edward2a commented 5 years ago

In our case, we'd like to use a shared PubSub topic for different GCP/GKE application instances. It looks like it would be so practical to have it like a resource to create if not existing but to never destroy. For the moment we are thinking about managing this specific topic independently (its also make sense but less ready to use as a whole) or to define the topic as a null_resource with a command to create and just a message when destroying. We could have this kind of needs for storage buckets too.

@vincbe I would not say it could not fit that use case, but personally, I would treat that PubSub topic as a piece of shared infrastructure, hence deploy it as a core service and use remote state to consume the resoure