`lifecycle` meta-argument cannot be updated in state after the resource is created

[frankcaoyun]

Terraform Version

Terraform v1.13.1
on darwin_arm64
+ provider registry.terraform.io/hashicorp/google v6.19.0
+ provider registry.terraform.io/hashicorp/null v3.2.4

Terraform Configuration Files

resource "google_compute_region_ssl_certificate" "test_ssl_certificate" {
  name_prefix = "test-ssl-certificate"
  description = "Test SSL Certificate"
  region      = "europe-west4"
  private_key = data.google_secret_manager_secret_version.test_ssl_key_file.secret_data
  certificate = data.google_secret_manager_secret_version.test_ssl_crt_file.secret_data
  lifecycle {
    create_before_destroy = false
  }
}

Debug Output

NA

Expected Behavior

When the value for create_before_destroy is added / removed / updated, it should show the diff in the terrraform plan / apply output.

Actual Behavior

"No changes. Your infrastructure matches the configuration."

Steps to Reproduce

1. Create a resource (I've tested with google_compute_region_ssl_certificate, google_compute_instance_template, google_compute_region_target_https_proxy, google_compute_region_url_map) with (or without) lifecycle {create_before_destroy = true}
2. After the resource is created, confirm that the lifecycle block exists in the resource state file
3. Update / remove (or add) the value of the create_before_destroy key
4. Run terraform plan
5. You should see "No changes..."

Additional Context

No response

References

No response

Generative AI / LLM assisted development?

No response

[jbardin]

Hi @frankcaoyun,

Thanks for filing the issue. This is a bit of a rough spot in the state management, as the user-facing interface for dealing with changes is intended to only take into account the resource instance state, it does not expose any metadata associated with the instance. You can force the update of all information using a -refresh-only plan which is designed to be applied with no instance changes present.

This however isn't generally a problem, because something like create_before_destroy only has an effect if there are other changes in the configuration. Can you show an example of the problem you are trying to solve?

Thanks!

[frankcaoyun]

Hi @jbardin , thanks for the response.

Basically it was the same issue as this post.

We had multiple compute instances as backend services attached to the url map. When we try to remove one of it using out CI pipeline running terraform run-all apply (actually it's terragrunt in our case but it should be the same), it failed because terraform is trying to remove the backend service first before updating the url map. Because the url_map resource was created first without the lifecycle block, simply adding the block with the create_before_destroy key doesn't solve the problem. It was found that only by destroying and recreating the resource will the create_before_destroy take effect, and it can't be modified unless the resource gets recreated.

It took me quite a while to narrow down the issue, because initally the behaviour wasn't consistent when create_before_destroy is being added, and I only realize the difference when adding it before / after the resource is created.

Is this the expected behaviour with the Meta-arguments in general?

[jbardin]

Thanks @frankcaoyun. If I understand correctly, you want to simultaneously reduce the number of instances of a resource while also changing create_before_destroy?

I could see that as being a hole in the current methodology, which is worked around by manually refreshing the state. There is an old test that codifies the reasoning, because we know resources can be removed in a valid order based on what was stored in state, and overriding part of that order with new configuration can cause cycles. I feel like there should be a more selective way to update the order when it only involved expanded resources which still have config, but that is tricky because the order can be forced from dependents, so there may still be something undecidable in there I'm missing.