Terraform v0.11.3
resource "azurerm_virtual_machine_extension" "AppServer_DSC" {
name = "${format("${var.customerProject}${var.environment}${var.machineAcronyms["AppServer"]}%02d", count.index + 1)}-dsc"
location = "${var.location}"
resource_group_name = "${azurerm_resource_group.rg.name}"
virtual_machine_name = "${element(azurerm_virtual_machine.AppServer.*.name, count.index)}"
publisher = "Microsoft.Powershell"
type = "DSC"
type_handler_version = "${var.dsc_extension}"
auto_upgrade_minor_version = true
depends_on = ["azurerm_storage_share.fileShare"]
count = "${var.AppServer_Specs["Number_of_Machines"]}"
}
resource "azurerm_virtual_machine_extension" "WebServer_DSC" {
name = "${format("${var.customerProject}${var.environment}${var.machineAcronyms["WebServer"]}%02d", count.index + 1)}-dsc"
location = "${var.location}"
resource_group_name = "${azurerm_resource_group.rg.name}"
virtual_machine_name = "${element(azurerm_virtual_machine.WebServer.*.name, count.index)}"
publisher = "Microsoft.Powershell"
type = "DSC"
type_handler_version = "${var.dsc_extension}"
auto_upgrade_minor_version = true
depends_on = ["azurerm_storage_share.fileShare"]
count = "${var.WebServer_Specs["Number_of_Machines"]}"
}
VM extensions, specifically DSC extensions, should have the ability to depend on other DSC extensions being deployed before starting. This functionality is needed when environments are tied together in a specific order.
This works just fine when deploying only one machine of each type but when using count, this cannot work due to the depends_on property not supporting the ability to loop through count for each vm extension.
It fails the planning step due to interpolation not being supported in the depends_on value.
Hi @PleaseStopAsking!
depends_on creates relationships between configuration blocks (or, more accurately, the graph nodes that represent those configuration blocks) rather than individual instances. If you have a resource block with count and another block depends_on that block, the latter block will be processed after _all_ counted instances have been processed. This is unfortunately more fundamental than a lack of interpolation support: the dependency graph does not consider these different instances as separate nodes today.
With that said, there may be some other way to achieve what you need to achieve here. I'm not sure I fully understand your use-case since I'm not very familiar with Azure concepts. If you could share the configuration you _wanted_ to write (accepting that Terraform today considers it invalid) and explain a little about what sequence of operations you need then perhaps we can find a different way to express the same thing.
@apparentlymart
Thanks for the quick response. Without sending everything and to keep the example straight forward, I would like to force the AppServer_DSC extensions (regardless of how many in the count) to complete successfully before moving onto the WebServer_DSC extensions (again, regardless of the number).
The AppServer needs to be configured a specific way (via DSC) before the WebServer can connect to it so in turn, I would like to configure the AppServers before moving onto the WebServer configuration. Another use-case would be deploying our Domain Controller servers before moving on to our workstation servers that are then joined to the domain running on the DC servers.
If having the full template makes it easier to follow, please let me know and I can sanitize before adding it.
Thanks,
resource "azurerm_virtual_machine_extension" "AppServer_DSC" {
name = "${format("${var.customerProject}${var.environment}${var.machineAcronyms["AppServer"]}%02d", count.index + 1)}-dsc"
location = "${var.location}"
resource_group_name = "${azurerm_resource_group.rg.name}"
virtual_machine_name = "${element(azurerm_virtual_machine.AppServer.*.name, count.index)}"
publisher = "Microsoft.Powershell"
type = "DSC"
type_handler_version = "${var.dsc_extension}"
auto_upgrade_minor_version = true
depends_on = ["azurerm_storage_share.fileShare"]
count = "${var.AppServer_Specs["Number_of_Machines"]}"
}
resource "azurerm_virtual_machine_extension" "WebServer_DSC" {
name = "${format("${var.customerProject}${var.environment}${var.machineAcronyms["WebServer"]}%02d", count.index + 1)}-dsc"
location = "${var.location}"
resource_group_name = "${azurerm_resource_group.rg.name}"
virtual_machine_name = "${element(azurerm_virtual_machine.WebServer.*.name, count.index)}"
publisher = "Microsoft.Powershell"
type = "DSC"
type_handler_version = "${var.dsc_extension}"
auto_upgrade_minor_version = true
depends_on = ["azurerm_storage_share.fileShare", element(azurerm_virtual_machine_extension.AppServer_DSC.*.name, count.index)]
count = "${var.WebServer_Specs["Number_of_Machines"]}"
}
Hi @PleaseStopAsking. Thanks for sharing that additional information.
If I'm understanding correctly your goals, I think it should be sufficient to depend on azurerm_virtual_machine_extension.AppServer_DSC as a whole, which will force all of the instances created by that block to be created before any instances of azurerm_virtual_machine_extension.WebServer_DSC are created. For example:
resource "azurerm_virtual_machine_extension" "WebServer_DSC" {
# ... (unchanged arguments) ...
depends_on = [
"azurerm_storage_share.fileShare",
"azurerm_virtual_machine_extension.AppServer_DSC",
]
count = "${var.WebServer_Specs["Number_of_Machines"]}"
}
Although this is not as precise as what you were trying to express, it should still produce the relative ordering you need.
@apparentlymart
As of now, there are no requirements to depend on individual instances within the dsc block so your suggestion could work. I will test it out and report back.
@apparentlymart
Tested workflow and its is working as expected. Thank you very much for the assist.
Great! Thanks for following up.
Since you've found a workable approach, I'm going to close this for now. In future we may change the graph model so that each counted instance is a separate graph node and allow more precise dependencies to be expressed, but this will not happen in the foreseeable future so we'll wait and see how that pans out and open a fresh issue for that later once we know more specifically what will change here.
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.
Most helpful comment
Great! Thanks for following up.
Since you've found a workable approach, I'm going to close this for now. In future we may change the graph model so that each
counted instance is a separate graph node and allow more precise dependencies to be expressed, but this will not happen in the foreseeable future so we'll wait and see how that pans out and open a fresh issue for that later once we know more specifically what will change here.