Until #3116 is finally fixed - -force_destroy flag ? -exclude some targets from plan ?

[earzur]

Terraform Version

Terraform v0.11.7
+ provider.aws v1.9.0
+ provider.template v1.0.0

Terraform Configuration Files

Volumes / other resources with

  # no interpolation in prevent_destroy :-(
  # lifecycle {
  #   prevent_destroy = "${var.prevent_destroy_volumes}"
  # }

  lifecycle {
    prevent_destroy = true
  }

With a complex stack and several branches - possibly with versioned modules in github, it is incredibly painful to maintain stack sources that would accomodate several different environments with different requirements.

I have a module that uses several modules and creates ~120 different resources.

I need to be able to perform tests on those, be able to destroy volumes from the test environment, and be unable to accidentally remove volumes from production.

lifecycle {
  prevent_destroy = true
}

is perfect, but just have a look at that output:

* module.operations_lb.module.graylog.aws_ebs_volume.graylog_es_data[0]: aws_ebs_volume.graylog_es_data: the plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag.
* module.influxdb.aws_ebs_volume.influxdb_data: aws_ebs_volume.influxdb_data: the plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag.
* module.operations_lb.module.graylog.aws_ebs_volume.graylog_es_data[1]: aws_ebs_volume.graylog_es_data: the plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag.
* module.platform_mongodb.aws_ebs_volume.mongo_data: aws_ebs_volume.mongo_data: the plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag.
* module.platform_elasticsearch.aws_ebs_volume.es_data[2]: aws_ebs_volume.es_data: the plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag.
* module.influxdb.aws_ebs_volume.influxdb_wal: aws_ebs_volume.influxdb_wal: the plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag.
* module.operations_lb.module.grafana.aws_ebs_volume.grafana_data: aws_ebs_volume.grafana_data: the plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag.
* module.operations_lb.module.graylog.aws_ebs_volume.graylog_es_data[2]: aws_ebs_volume.graylog_es_data: the plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag.
* module.platform_elasticsearch.aws_ebs_volume.es_data[1]: aws_ebs_volume.es_data: the plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag.
* module.operations_lb.module.graylog.aws_ebs_volume.graylog_mongo_data: aws_ebs_volume.graylog_mongo_data: the plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag.
* module.platform_elasticsearch.aws_ebs_volume.es_data[0]: aws_ebs_volume.es_data: the plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag.

I cannot destroy my stack, I cannot "exclude" a resource from a terragrunt destroy ... plan, i cannot force terraform to destroy them. My only option is to edit every modules where prevent_destroy is true.

Would it be possible add a -force_destroy flag with similar semantics as -target which would override the lifecycle attribute for some specific resources ?

or a -exclude that would do the exact opposite of -target ?

References

• Cannot use interpolations in lifecycle attributes #3116

[roadtest]

+1. some old tricks don't work any more - #3874

[apparentlymart]

Hi @earzur! Sorry that Terraform isn't working well for your needs right now.

There is some discussion of an "inverse target" over in #2253. That's probably the best way to go for now, as it's a feature that would still remain useful even after the workflow for prevent_destroy has been refined.

terraform apply -target=!module.operations_lb.module.graylog.aws_ebs_volume.graylog_es_data[0]

There is a PR #3366 open for this, which has unfortunately been open for some time but is on an area of the Terraform Core code that's been changing quickly for other reasons and so it's now in conflict. We (the Terraform team at HashiCorp) are planning to shift our focus onto CLI workflow stuff once we get past the current work to improve the configuration language for the next major release, and an inverse-target flag and the prevent_destroy work are likely to be in scope for that set of changes although we'll know more once we get stuck in and do some design/prototyping.

[zoobab]

Bash does not like the "!" on the cli.