locals {
input_cloudlogs_view = yamldecode(file(var.config_cloudlogs_view)).cloudlogs_view
}
resource "ibm_logs_view" "logs_view_instance_yaml" {
instance_id = var.instance_id
region = var.region
for_each = { for x in local.input_cloudlogs_view : x.name => x }
name = each.value.name
search_query {
query = each.value.query
}
time_selection {
quick_selection {
caption = "Last 24 hours"
seconds = 86400
}
}
}
output "view_created" {
value = [
for k in ibm_logs_view.logs_view_instance_yaml : "${k.name}"
]
}
output "view_yaml" {
value = [
for k in local.input_cloudlogs_view : "${k.name}"
]
}
After executing, we can verify the ressources get from the yaml and in the ressource list “ibm_logs_view.logs_view_instance_yaml”, the are well ingered in the right order
Force order in same item is not possible because this need the resource depends on the previous resource in same “list”, but when you decide for “for_each” you choose for parallell creation of the itens.
This order is because the responde of the provider for your resources.
Try access resources result using set(…) and your itens will respect your order, ignoring order of creation.
Normally, you can use implicit dependencies (via reference) or explicit depends_on to force ordering (though explicit depends are less preferred). But in the case where you’re using an iterator, I think you can’t really control order of resource creation, even if you force order on the data structure because of the reason you mentioned (Terraform’s internal parallelism).
I’m unsure what the earlier reply about toset is intending to convey, but sets and maps are unordered data structures. You cannot use toset to create order via something which inherently has no order.
As for ordering of operations, it is correct that there is no order imposed within resources expanded via count or for_each, nor is there any way to define such an order. In fact multiple instance changes are not only unordered, but they may be run concurrently as well.