I’m also running into this. I currently use the azurerm_managed_disk resource to create several disks and attach them with the azurerm_virtual_machine_data_disk_attachment resource, both using a for_each to loop over an input variable containing the disks I want to create and their attributes.
Funnily enough, the first few times I tested my module, the disks attached in the intended order, but now I’m seeing that the initial results are not indicative of the behavior of the module. Short of breaking out each disk into its own respective creation and attachment resources (which would set a finite amount of disks I could create and attach to any VM), I haven’t figured out a way to address this problem.
It might be nice if the VM resources (such as azurerm_windows_virtual_machine) had a way to pass existing disk information to the resource so the disks could be attached in a serial manner after the VM is spun up, or perhaps a new resource altogether like what @apparentlymart suggested here:
The usecase for us is that we want the disks to be attached in a specific order so that scripts that run after the VM is created will initialize and map the disks in the OS even if the sizes are different (which we expect them to be).
If you ever figure anything out, please share! I am interested in what the solution would be.