Why did terraform not recognise that affected resources have been affected?

Terraform
2

Hi @jamiekt,

I think what happened here is that the provider planned replacement of snowflake_warehouse with the same name before and after, and so snowflake_warehouse.warehouse.name (assigned to warehouse_name in snowflake_warehouse_grant) didn’t change and therefore the provider considered the new desired state identical to the old desired state.

Of course, you have some additional information that Terraform did not: that apparently this API silently deletes all of the “warehouse grant” objects when a warehouse is deleted. Because Terraform isn’t aware of that hidden interaction, it understands the removal of the role from the warehouse grant as a change made outside of Terraform – by the remote API itself, in this case – and so tries to repair it on the next run as would be the case if you’d changed something manually in the system’s management UI.

In today’s Terraform you can inform Terraform about that hidden interaction like this:

resource "snowflake_warehouse_grant" "warehouse_usage_grant" {
  warehouse_name = snowflake_warehouse.warehouse.name
  privilege      = "USAGE"
  roles          = [snowflake_role.role.name]

  lifecycle {
    replace_triggered_by = [
      snowflake_warehouse.warehouse.name,
    ]
  }
}

In an ideal world, the provider would’ve automatically informed Terraform about that relationship between these two objects so that you would not need to write anything. However, the Terraform provider protocol currently lacks any way to describe such relationships. That gap is what this design issue is about:

That issue discusses a way to allow providers to “talk about” related objects when planning changes for a specific object, which would then in principle allow the provider to express something like “deleting object A implicitly deletes object B”, which would then in turn allow Terraform to infer the extra actions required to deal with the implicit change, so that you’d no longer need to explicitly configure replace_triggered_by.

However, that issue is really just a problem statement with only very early ideas on how to solve it. I have some further work on this in a non-public place where I collected some more specific examples from discussions with provider developers, and it does still seem like a promising direction, so hopefully eventually we’ll have time to do some more concrete design work for it, and then implement something in this area.

1 Like