Force specific order of nested block lists

[jhyot]

Current Terraform Version

Terraform v1.0.4

Use-cases

If a resource has a list of nested blocks (multiple nested blocks of the same type), it seems that the order is not specified and cannot be controlled. If a property of one block is changed, it can happen that the order of the blocks changes, and all blocks are changed, instead of changing just the one.

Attempted Solutions

Did not find any solutions for this.

Proposal

I understand that Terraform has no way of a priori knowing whether a list has been reordered, especially if it gets the data from some API not under its control.

Maybe supplying an optional specific ordering key (any property of the block) would make the ordering deterministic where it is desired.

Or should the individual provider just make sure that the ordering is fixed/deterministic? I can open a ticket in the azurerm provider for my specific case if that's the preferred way.

[jbardin]

Hi @jhyot,

The order of list elements is set defined by the order in the configuration. Do you have an example of terraform re-ordering the list elements?

If the provider is re-ordering the elements in a list, there is not much terraform can do to prevent it, since the order of a list returned by the provider must be preserved.

[jhyot]

The issues comes up specifically in Azure Application Gateway Listeners (not important what they are, just some objects). There can be multiple "listeners" defined, they are represented as blocks in Terraform. If I change some listener manually, then Azure itself seems to reorder the listeners, and next time Terraform pulls the state it will find a different order, but does not know that only the order changed, and then it proceeds to recreate all listeners (because from its point, all properties of the listeners have changed).

I can't imagine that my example is the only one, so maybe it would be worth having some kind of mechanism to deal with it.

But also honestly, I only noticed that Azure itself is reordering them as I was looking closer into it just now. That seems anyway bad behaviour by Azure to me. So having a specific "fix"/"hack" for this API deficiency in this specific resource in the azurerm provider would be actually the way to go.

[jhyot]

Ok, actually found that there is already a ticket in azurerm: hashicorp/terraform-provider-azurerm#6896

[jbardin]

Thanks @jhyot! We can track the issue in the azurerm repo.

[github-actions]

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.