sdwan_data_ipv4_prefix_list_policy_object reports false positives on drift detection

[ivancesg]

Provider Version: CiscoDevNet/sdwan v0.7.1 (also reproduced in v0.6.2)

Issue: The sdwan_data_ipv4_prefix_list_policy_object resource incorrectly reports
changes in terraform plan when the current state matches the desired configuration.

Expected Behavior: terraform plan should show "No changes" when tfstate matches
the actual vManage configuration.

Actual Behavior: terraform plan shows additions (+) for entries and name
attributes that already exist with identical values in both tfstate and vManage.

Evidence:

• tfstate contains: "prefix": "10.30.192.0/22", "name": "GPC_dev_eastus2_Common"

    {
      "index_key": "eastus2_dev_Common",
      "schema_version": 0,
      "attributes": {
        "entries": [
          {
            "prefix": "10.30.192.0/22"
          }
        ],
        "id": "06bc5b86-bbec-426c-92aa-6f3d179297e7",
        "name": "GPC_dev_eastus2_Common",
        "version": 0
      },
  

• terraform plan shows: + prefix = "10.30.192.0/22", + name = "GPC_dev_eastus2_Common"

  module.GPC-tf-vmanage-dataprefix-module.sdwan_data_ipv4_prefix_list_policy_object.dataprefix["eastus2_dev_Common"] will be updated in-place

  ~ resource "sdwan_data_ipv4_prefix_list_policy_object" "dataprefix" {
  ~ entries = [
  + {
  + prefix = "10.30.192.0/22"
  },
  ]
  id = "06bc5b86-bbec-426c-92aa-6f3d179297e7"
  + name = "GPC_dev_eastus2_Common"
  ~ version = 0 -> (known after apply)
  }

• This occurs on multiple resources, not just one specific instance

• Affects both single-entry and multi-entry prefix lists

Impact: Forces users to implement ignore_changes lifecycle rules, preventing
legitimate configuration updates.

Workaround: Using lifecycle { ignore_changes = [entries, name] }

[tzarski0]

Hi @ivancesg, thank you for submitting the issue. Could you please provide the exact configuration that causes the problem? We do not observe this problem in our test data.

[ivancesg]

Hi @tzarski0 , thank you for the quick response! The case is difficult to reproduce exactly, as I obtain the data from the Azure provider and process it to sort it and create prefixes with Azure VNET addressing. Here's the exact configuration that reproduces the issue:

---MODULE CALL---
module "GPC-tf-vmanage-dataprefix-module" {
source = "./modules/GPC-tf-vmanage-dataprefix-module"
data_prefixes = {
for key, items in {
for vnet in values(merge(
module.network_landing_vnets,
module.network_common_vnets,
module.network_management_vnets,
module.network_vdi_vnets
)) :
"${vnet.vnet_location}${var.global_settings.environment}${replace(replace(replace(replace(vnet.vnet_business_unit, " ", ""), "(", ""), ")", ""), "&", "")}" => {
cidrs = sort(tolist(vnet.vnet_address_space))
business_unit = replace(replace(replace(replace(vnet.vnet_business_unit, " ", ""), "(", ""), ")", ""), "&", "")
environment = var.global_settings.environment
location = vnet.vnet_location
}...
} : key => {
cidrs = sort(tolist(toset(flatten([for item in items : item.cidrs]))))
business_unit = items[0].business_unit
environment = items[0].environment
location = items[0].location
}
}
environment = var.global_settings.environment
vmanage_username = var.vmanage_username
vmanage_password = var.vmanage_password
}

---VARIABLES---
variable "data_prefixes" {
type = map(object({
cidrs = list(string)
business_unit = string
environment = string
location = string
}))
}

variable "environment" {
description = "Nombre del entorno (environment)"
type = string
}

---LOCALS + RESOURCE---

locals {

#I check the Data Prefix name by creating a variable “base_name” that uses variables from azurerm and, if there are any duplicates, I add “1, 2, 3,...” at the end. I also limit it to 32 characters, which is the vManage limit. Finally, I do a “sort” to order the prefixes and prevent them from entering the resource in a disordered manner.

base_names = {
for key, value in var.data_prefixes : key => substr("GPC_${value.environment}${value.location}${value.business_unit}", 0, 32)
}

name_list = values(local.base_names)

name_counts = {
for name in toset(local.name_list) : name => length([
for other_name in local.name_list : other_name if other_name == name
])
}

unique_names = {
for key, base_name in local.base_names : key => (
local.name_counts[base_name] > 1 ?
"${substr(base_name, 0, 31)}${
index(
sort([
for k in keys(local.base_names) : k
if local.base_names[k] == base_name
]),
key
) + 1
}" :
base_name
)
}

ordered_data_prefixes = {
for key in sort(keys(var.data_prefixes)) : key => var.data_prefixes[key]
}
}

#For each Data Prefix, I apply the resource, adding the prefixes in CIDR format from the azurerm data.

resource "sdwan_data_ipv4_prefix_list_policy_object" "dataprefix" {
for_each = local.ordered_data_prefixes
name = local.unique_names[each.key]
entries = [
for prefix in sort(each.value.cidrs) : {
prefix = prefix
}
]
}

Please let me know if you need anything else.
Thank you very much in advance for your support.

[tzarski0]

I see you are using some custom modules. I don't see that happening in our modules: https://github.com/netascode/terraform-sdwan-nac-sdwan/tree/main
Since this is a provider repository, does that happens also when you configure this resource directly with terraform without a module?