When moved block wants to force replace the destination resource and destroy the source resource?

Terraform
1

Hi Fam,
I want to used moved block to replace the old resource with new one:

moved {
  from = module.stack.ibm_database.postgres_read_replica["abc"]
  to   = module.stack.ibm_database.postgresql["abc"]
}

but always got:

module.stack.ibm_database.postgresql["abc"] must be replaced
 resource "ibm_database" "postgresql" {
....
   version                 = "12" -> "14" # forces replacement
...
}

 # module.stack.ibm_database.postgres_read_replica["abc"] will be destroyed
 # (because key ["abc"] is not in for_each map)
  - resource "ibm_database" "replica" {
}

and this the terraform code:

resource "ibm_database" "postgresql" {
  for_each          = local.ibm_postgresql_instances
  name              = lookup(each.value, "name", "pg-${each.key}")
...
}
resource "ibm_database" "postgresql_read_replica" {
  for_each         = local.ibm_postgresql_instances_with_read_replica
  name             = "${lookup(each.value, "name", "${pg-${each.key}")}-read-replica"

I DO want to change the version from 12 to 14 when doing moved. Even due to version change, the existing destination resource will be replaced (it should NOT be), why the “from” resource will be destroyed? I dot not undersand this # (because key ["abc"] is not in for_each map). The keys never change.

Appreciate it if anyone can point out what is wrong.

2

Hi @wshao12,

Something is not aligning with your configuration, you do have a few different resource names in the information you’ve shown already:

You are moving ibm_database.read_replica to ibm_database.origin, but the output references ibm_database.postgresql and ibm_database.replica, and your configuration has yet another name: ibm_database.postgresql_read_replica, perhaps some of those inconsistencies explain what’s going on?

As for the information about # (because key ["abc"] is not in for_each map), the for_each expression is not yielding a collection with that value. I can’t tell why either from the information given, but that is the case, something else must have changed.

One thing to do is make sure you have no changes planned at all before adding the moved block to make it easier to understand what is going on, lots of concurrent changes can make it hard to pinpoint the causes of each change.

3

Hi @jbardin
Thanks for looking at my question. I fixed the consistencies, but the issue remains the same.
I am thinking to delete the primary state before doing moved plan to see if that is the root cause. Is there a way to test it locally first (so not to mess up with the real remote state?) ? maybe use a copy of plan and change something to see what happens?

4

Looks like I cannot change version and use moved at the same time. instead, I removed the state of old version and use import of new instance to replace the old one. Fixed.