sdwan_centralized_policy | API payload order being sorted (Urgent)
rrahimm opened this issue · 3 comments
we see a different behaviour just with resource sdwan_centralized_policy
In most TF providers we will see that the API will use the payload in the same order we handle them in the Terraform Module
but in this one, it is trying to do some sorting
For example, the Data Input is
traffic_data:
- policy_definition: TD_DEFINITION_T1-rrahimm
site_region_vpn:
- direction: service
region_list: RL-CORE-rrahimm
vpn_lists:
- VPN-LIST-TD-T2-rrahimm
- direction: tunnel
region_list: RL-CORE-rrahimm
vpn_lists:
- VPN-LIST-TD-T2-rrahimm
- direction: all
region_list: RL-GLOBAL-rrahimm
vpn_lists:
- VPN-LIST-TD-T1-rrahimm
- VPN-LIST-TD-T2-rrahimm
but the Terraform plan looks like this
# module.sdwan.sdwan_centralized_policy.centralized_policy["Super_policy_T2-rrahimm"] will be updated in-place
~ resource "sdwan_centralized_policy" "centralized_policy" {
~ definitions = [
+ {
+ entries = [
+ {
+ direction = "all"
+ region_list_ids = [
+ "bef11466-f66f-49b8-babc-04e1ab24d22b",
]
+ region_list_versions = [
+ "0",
]
+ vpn_list_ids = [
+ "0d27c30d-4f02-4dae-bf4b-56f3783ba79f",
+ "b6f43b71-490b-4628-9bc2-66c7948e1841",
]
+ vpn_list_versions = [
+ "0",
+ "0",
]
},
+ {
+ direction = "service"
+ region_list_ids = [
+ "1463ddbb-4f16-408e-8616-f66d3a445f83",
]
+ region_list_versions = [
+ "0",
]
+ vpn_list_ids = [
+ "0d27c30d-4f02-4dae-bf4b-56f3783ba79f",
]
+ vpn_list_versions = [
+ "0",
]
},
+ {
+ direction = "tunnel"
+ region_list_ids = [
+ "1463ddbb-4f16-408e-8616-f66d3a445f83",
]
+ region_list_versions = [
+ "0",
]
+ vpn_list_ids = [
+ "0d27c30d-4f02-4dae-bf4b-56f3783ba79f",
]
+ vpn_list_versions = [
+ "0",
]
},
]
+ id = "88cfa137-9de6-4feb-a3eb-ab1c1b2ded23"
+ type = "data"
+ version = 37
},
# (2 unchanged elements hidden)
]
id = "54c7b134-ad1f-4291-9cf9-526250f9e620"
name = "Super_policy_T2-rrahimm"
~ version = 7 -> (known after apply)
# (1 unchanged attribute hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.
module.sdwan.sdwan_centralized_policy.centralized_policy["Super_policy_T2-rrahimm"]: Modifying... [id=54c7b134-ad1f-4291-9cf9-526250f9e620]
module.sdwan.sdwan_centralized_policy.centralized_policy["Super_policy_T2-rrahimm"]: Modifications complete after 6s [id=54c7b134-ad1f-4291-9cf9-526250f9e620]
as you can see above, in our YAML the direction order is service, tunnel and then all
but TF provider make it all, service and tunnel
i confirmed our TF Module is not doing this order swapping. Is this something done on purpose in TF Provider
https://github.com/netascode/terraform-sdwan-nac-sdwan/blob/main/sdwan_centralized_policies.tf
The order swapping seems not a requirement of the SDWAN configurations, as the GUI allows them to be put in any order.
entries is a "Set" in Terraform, which is a collection of unique items not having any ordering. Which means the order of elements is of no significance. Apparently TF "re-orders" the elements when displaying them in the plan output, but again, it should not make a difference. Could you explain where this creates an issue or was it just a question why this is the case?
Hello @danischm
Here's a summary of this.
the impact we are seeing currently is on the Robot Scripts we have developed so far.
On several items that are listed in the API response, the Robot scripts have assumed that the API response List is in the same order as the configuration YAML List to make the comparison simpler. The current 2-step logic the robot uses is, to check if the List Lengths are the same and then check if the same index on both lists is identical.
This still holds good on a few places where the API response has list items.
Now, if the response List is not going to be in the same order as we construct in TF Modules - then the robot scripts have to find a different logic to handle this. Involving some re-work on already published scripts.
Taken offline and confirmed there is nothing to be changed on the provider side.