Add "create_without_destroy" lifecycle

[tmshn]

This is feature request for the Terraform core.

I'd like to have a new lifecycle option called create_without_destroy.
When you update an immutable resource with this option, first it creates the new resource (like create_before_destroy) and later DO NOT destroy the unused old resource (unlike create_before_destroy) but just cease to track it.

Terraform Version

Terraform v0.7.7

Affected Resource(s)

• Terraform core

Example Usage

Most typical use case is with the AWS launch configuration.

Updating an AWS launch configuration in Terraform (with or without create_before_destroy) leads to destroying itself, and hence destroying the EC2 instances configured by it.

Newly proposed create_without_destroy option can avoid this problem.

resource "aws_launch_configuration" "as_conf" {
    name_prefix = "terraform-lc-example-"
    image_id = "${data.aws_ami.ubuntu.id}"
    instance_type = "t1.micro"

    lifecycle {
      create_without_destroy = true
    }
}

Expected Behavior

Creating and destroying this resource should be done as usual.

Updating this resource should be done in a following way:

1. Creating new resource with new configuration
2. Replace the tie to the Terraform (i.e., .tfstate) from the old resource to the new resource

The old unused resource should be left undeleted.

Note

I was planning to implement it, should wait for the series of updates on the apply graph (including #9388) and use -Xnew-apply?

[yruss972]

Would like to have this but continue to track the state of the original resource, possibly by copying it into an auto-generated workspace.

The main concern is that RDS changes which require replacing instances don't need to be so eager about destroying the old ones. We could achieve this by maintaining multiple sets of RDS but create without destroy would be much simpler.

In the happy path, the old DB could be destroyed in a subsequent run using the generated workspace state. In case of a failure, the old DB could still be useful.

[amancevice]

This would also be great for aws_s3_bucket_object and aws_lambda_layer_version resources. Consider uploading a Lambda Layer package to S3 and publishing a new version with each new artifact:

resource "aws_s3_bucket_object" "lambda_layer" {
  bucket = "my-lambda-layers"
  key    = "my-project/${var.version}.zip"
  source = "package.zip"

  lifecycle {
    create_without_destroy = true
  }
}

resource "aws_lambda_layer_version" "lambda_layer" {
  s3_bucket           = aws_s3_bucket_object.lambda_layer.bucket
  s3_key              = aws_s3_bucket_object.lambda_layer.key
  layer_name          = "my-layer"
  compatible_runtimes = ["ruby2.5"]

  lifecycle {
    create_without_destroy = true
  }
}

As var.version changes new objects are uploaded, and a new layer version is created, but old S3 objects and layer versions are left in place.

[rgarrigue]

Another use case. I want to

• Create a (postgres) database (on AWS RDS)
• Add extensions
• Use it
• Drop it

I can't do that easily because the data rely on extensions, hence postgres refuses to delete the extensions, hence Terraform fails.

[tmshn]

I close this issue as it can be merged into following issue (which seems to be more active).
#15485

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.