Excessive plan when removing element from a list

Terraform Providers Plugin Development
1

I have a resource that manages multiple API objects as a list:

			"rules": rsschema.ListNestedAttribute{
				Required:     true,
				Optional:     false,
				Computed:     false,
				Sensitive:    false,
				NestedObject: [...],
			},

If I now create a resource that manages three-element list of objects, and later modify my HCL file to drop one of the list elements like in below example, plan shows that all elements in the list are being moved up one by one. Is there some special tombstone element I should replace “rule-1” object to make terraform show a plan where single element is being removed from the list?

resource "rules" "some_rules" {
  rules = [
    # This item is being removed in the `terraform apply`
    # {
    #   name                  = "rule-1",
    # },
    {
      name                  = "rule-3",
    },
    {
      name                  = "rule-2",
    },
  ]
}
2

Hi @kklimonda-cl,

There’s not really any way to avoid this, because each element is actually being moved up by one index. This however isn’t normally a problem unless you are somehow relying on that index being static for some other reason.

From Terraform’s perspective the entire rules list is is taken as a single value and that as a whole is what was changed. Since that list value is coming from the configuration, then the provider cannot alter that list by inserting a different value as a placeholder, the new list is what the provider must use to create the plan.

3

Whether it’s a problem (a disruptive API event) vs. it merely looks like a dramatic change is probably a function of how the provider’s Update() works.

If the API supports surgically removing one item from the middle of the list, the provider could conceivably notice that this is what’s required, and then perform the appropriate operation.

The user-facing plan output would still look dramatic, but the action taken doesn’t need to be.

It might be worth considering changing the provider schema to make these rules a set (perhaps with a ruleset position attribute), or a map (keyed by position number).

My perfect world would be to extend the SetNestedAttribute schema to include a KeyAttribute so that we can refer to set members not by value, but by key.

Maybe a KeyedSetNestedAttribute?