We need a way to protect / mark stateful resources in our plans

[raymond....@replicon.com]

We'd like to improve the safe handling of our stateful resources during the plan and apply process. 

Scenario

- Many stateless (ephemeral EC2 instances or whatever) resources.

- Many stateful resources (RDS, RabbitMQ, etc.)

- X number of remote state files, with locking

- Y number of users who can modify infrastructure / change state

Problem

- The state files grow to be quite long (even with modularization, separation of concerns) and be very unwieldy.

- Easy to miss a change in a plan and accidentally destroy a stateful resource.

It would be really helpful to have the capability to denote a stateful resource.  Even if it is just set manually (not always possible to infer statefulness). 

I know there has been discussion previously of terraform output templates, but that fix seems symptomatic. We really just need a way to denote statefulness, without bolting on additional tooling. I do agree with the principle of treating resources as cattle and not pets, but we still don't want to be blasting queues and databases and causing impact our customers if we can avoid it.

Eager to hear everyone's thoughts on this, including any suggestions on workarounds.

- Raymond

[Paddy Carver]

Have you tried lifecycle.prevent_destroy? https://www.terraform.io/docs/configuration/resources.html#prevent_destroy

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/terraform/issues
IRC: #terraform-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Terraform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terraform-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/terraform-tool/38f0c9b7-804c-43d9-a73c-19539e51ce1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[raymond....@replicon.com]

Hi Paddy I think the lifecycle rules will do what we need. Embarrassed I missed this in the doc!

Would still be good to have some additional capabilities for plan's. Being able to meta-tag resources, or order-by.

On Thursday, December 7, 2017 at 1:56:08 PM UTC-7, Paddy Carver wrote:

Have you tried lifecycle.prevent_destroy? https://www.terraform.io/docs/configuration/resources.html#prevent_destroy

On Wed, Dec 6, 2017 at 2:08 PM, <raymond....@replicon.com> wrote:

We'd like to improve the safe handling of our stateful resources during the plan and apply process. 

Scenario

- Many stateless (ephemeral EC2 instances or whatever) resources.

- Many stateful resources (RDS, RabbitMQ, etc.)

- X number of remote state files, with locking

- Y number of users who can modify infrastructure / change state

Problem

- The state files grow to be quite long (even with modularization, separation of concerns) and be very unwieldy.

- Easy to miss a change in a plan and accidentally destroy a stateful resource.

It would be really helpful to have the capability to denote a stateful resource.  Even if it is just set manually (not always possible to infer statefulness). 

I know there has been discussion previously of terraform output templates, but that fix seems symptomatic. We really just need a way to denote statefulness, without bolting on additional tooling. I do agree with the principle of treating resources as cattle and not pets, but we still don't want to be blasting queues and databases and causing impact our customers if we can avoid it.

Eager to hear everyone's thoughts on this, including any suggestions on workarounds.

- Raymond

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/terraform/issues
IRC: #terraform-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Terraform" group.

To unsubscribe from this group and stop receiving emails from it, send an email to terraform-too...@googlegroups.com.