Invalid plan error when using lifecycle ignore_changes with deprecated relationship fields (DCNE-548)

[jasonjuenger]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v1.5.7
terraform-provider-aci v2.17.0

APIC version and APIC Platform

• V 5.2(8e) and on-prem

Affected Resource(s)

• aci_tenant
• aci_vrf
• (Likely other resources with deprecated relationship fields migrated to terraform-plugin-framework)

Terraform Configuration Files

# Minimal reproduction case - tenant resource with lifecycle ignore_changes
resource "aci_tenant" "test" {
  name        = "test-tenant"
  description = "Test tenant for bug reproduction"
  
  # This lifecycle block should prevent drift on deprecated fields
  # but instead causes "Provider produced invalid plan" errors
  lifecycle {
    ignore_changes = [
      relation_fv_rs_tenant_mon_pol,
    ]
  }
}

# VRF resource showing same issue with multiple relationship fields
resource "aci_vrf" "test" {
  parent_dn   = aci_tenant.test.id
  name        = "test-vrf"
  description = "Test VRF for bug reproduction"
  
  lifecycle {
    ignore_changes = [
      relation_fv_rs_bgp_ctx_pol,
      relation_fv_rs_ctx_to_ep_ret,
      relation_fv_rs_ctx_to_ext_route_tag_pol,
      relation_fv_rs_ospf_ctx_pol,
    ]
  }
}

Debug Output

Debug output shows the provider is generating plan values that do not conform to Terraform's planning rules. The provider forces plan values to "default" even when configuration has empty strings and lifecycle ignore_changes is set.

Panic Output

None, this is a tf plan error.

Expected Behavior

When lifecycle { ignore_changes } is specified for relationship fields:

1. Plan generation should respect ignore_changes
2. If a field is not configured or set to empty string, the plan should reflect that, not replace the empty string with "default"
3. The provider should not push changes to ACI for fields in ignore_changes
4. terraform plan should complete successfully without "Provider produced invalid plan" errors

Actual Behavior

The provider generates an "invalid plan" error that violates Terraform's core planning rules:

Error: Provider produced invalid plan

Provider "registry.terraform.io/ciscodevnet/aci" planned an invalid value
for aci_tenant.test.relation_to_monitoring_policy.monitoring_policy_name:
planned value cty.StringVal("default") does not match config value
cty.StringVal("") nor prior value cty.StringVal("").

This is a bug in the provider, which should be reported in the provider's
own issue tracker.

Steps to Reproduce

1. Import existing ACI tenant/VRF resources that do not have monitoring policies assigned in ACI (ex. "")
2. Configure terraform resources without specifying relationship fields
3. Add lifecycle { ignore_changes } for deprecated relationship fields
4. Run terraform plan
5. Observe "Provider produced invalid plan" error

Important Factoids

• There does not appear to be a workaround for this issue. Configuring the fields with empty strings, omitting them, or using lifecycle ignore_changes does not resolve the issue
• When relationship fields are configured, the provider pushes actual changes to ACI (empty strings become "default" policies). This applies both to the deprecated fields and the new fields that replace those deprecated fields.

References

• Provider Framework Migration: This appears related to the migration from terraform-plugin-sdk/v2 to terraform-plugin-framework starting in v2.16.0

[shrsr]

@jasonjuenger Thank you for opening the issue.
After the provider's migration, ignore_changes only works when it targets the exact attribute paths that exist in the current provider schema and state. As a result, ignoring the old names does nothing but ignoring the new, actual paths tells Terraform to suppress differences on the fields that are really changing.

Can you try the following config with the ignore_changes consisting of the new relationship attributes as opposed to their deprecated counterparts?

resource "aci_tenant" "test" {
  name        = "test-tenant"
  description = "Test tenant for bug reproduction"
  
  lifecycle {
    ignore_changes = [
      relation_to_monitoring_policy,
    ]
  }
}

resource "aci_vrf" "test" {
  parent_dn   = aci_tenant.test.id
  name        = "test-vrf"
  description = "Test VRF for bug reproduction"
  
  lifecycle {
    ignore_changes = [
      relation_to_bgp_timers,
      relation_to_end_point_retention_policy,
      relation_to_l3out_route_tag_policy,
      relation_to_ospf_timers,
    ]
  }
}

[jasonjuenger]

@shrsr Thank you for looking into this. Here is the output of the plan when ignoring changes to the new relationship attributes. If I proceed with the apply it will replace the existing "" values for the relationships with "default"

/usr/local/bin/actions-runner/_work/_temp/51af674e-0791-420e-834d-96b154de7378/terraform-bin plan -detailed-exitcode -out=tfplan -var=aci_username=*** -var=aci_password=*** -var=aci_url=*** -var=aci_insecure=true
aci_tenant.tenants["test"]: Refreshing state... [id=uni/tn-test]
aci_vrf.vrfs["vrf1"]: Refreshing state... [id=uni/tn-test/ctx-vrf1]

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # aci_tenant.tenants["test"] will be updated in-place
  ~ resource "aci_tenant" "tenants" {
        id                            = "uni/tn-test"
        name                          = "test"
      ~ relation_fv_rs_tenant_mon_pol = "uni/tn-common/monepg-default" -> (known after apply)
        tags                          = []
        # (4 unchanged attributes hidden)
    }

  # aci_vrf.vrfs["vrf1"] will be updated in-place
  ~ resource "aci_vrf" "vrfs" {
        id                                        = "uni/tn-test/ctx-vrf1"
        name                                      = "vrf1"
      ~ pc_tag                                    = "49153" -> (known after apply)
      ~ relation_fv_rs_bgp_ctx_pol                = "uni/tn-common/bgpCtxP-default" -> (known after apply)
      + relation_fv_rs_ctx_mon_pol                = (known after apply)
      ~ relation_fv_rs_ctx_to_ep_ret              = "uni/tn-common/epRPol-default" -> (known after apply)
      ~ relation_fv_rs_ctx_to_ext_route_tag_pol   = "uni/tn-common/rttag-default" -> (known after apply)
      ~ relation_fv_rs_ospf_ctx_pol               = "uni/tn-common/ospfCtxP-default" -> (known after apply)
      ~ scope                                     = "2621441" -> (known after apply)
        tags                                      = []
      ~ tenant_dn                                 = "uni/tn-test" -> (known after apply)
        # (19 unchanged attributes hidden)
    }```

[shrsr]

Were you meaning to ignore relation_to_monitoring_policy whose deprecated counterpart is relation_fv_rs_ctx_mon_pol ?

resource "aci_vrf" "test" {
  parent_dn   = aci_tenant.test.id
  name        = "test-vrf"
  description = "Test VRF for bug reproduction"
  
  lifecycle {
    ignore_changes = [
      relation_to_bgp_timers,
      relation_to_end_point_retention_policy,
      relation_to_l3out_route_tag_policy,
      relation_to_ospf_timers,
      relation_to_monitoring_policy,
    ]
  }
}

[jasonjuenger]

The tfplan output is the same as above, whether or not I include relation_to_monitoring_policy in the ignore_changes list

[shrsr]

@jasonjuenger Can you please tell us why you are using lifecycle { ignore_changes } in your config? Did you come across any issues before using lifecycle?

[jasonjuenger]

If I use either the deprecated fields (relation_fv_rs_*) or the new fields (relation_to_*) it will result in a change on our fabric, even when matching the tfvars value to what we have on our fabric.

If we set the deprecated fields to the production value "" the plan will not show the deprecated field as changing, but it will show the new field as changing from "" to "default".

Conversely, if we set the new fields to the production value the plan will not show the new field as changing, but it will show the deprecated field as changing with "known after apply". When we apply that plan it changes the value on the fabric from "" to "default".

Basically, no matter what combination of field, new or deprecated, we set to the correct production value of "" it will always change it to "default" on the fabric. The goal of using lifecycle ignore_changes was to avoid the issue entirely.

[shrsr]

Can you please share a minimal config that's causing the above issue without the lifecycle block?

[jasonjuenger]

Here is an example without lifecycle ignore or a monitoring policy defined along with the plan output. It results in a change of the monitoring policy in ACI from "" to "default"

terraform {
  required_providers {
    aci = {
      source  = "CiscoDevNet/aci"
      version = "~> 2.17"
    }
  }
}

# Configure the ACI Provider
provider "aci" {
  username = var.aci_username
  password = var.aci_password
  url      = var.aci_url
  insecure = var.aci_insecure
}

resource "aci_tenant" "tenants" {
  for_each = var.tenant_config.tenants
  
  name        = each.key
  description = each.value.description
  annotation  = each.value.annotation
  
}

And here is the plan output:

# aci_tenant.tenants["test"] will be updated in-place
  ~ resource "aci_tenant" "tenants" {
      ~ annotation                    = "orchestrator:ansible" -> "orchestrator:terraform"
        id                            = "uni/tn-test"
        name                          = "test"
      ~ relation_fv_rs_tenant_mon_pol = "uni/tn-common/monepg-default" -> (known after apply)
        tags                          = []
        # (4 unchanged attributes hidden)
    }

[shrsr]

@jasonjuenger I'm wondering if explicitly setting annotation to "orchestrator:ansible" will mask the diff? Can you please try that and let us know?

[jasonjuenger]

Correcting the value for the annotation field only removes the diff for that field, it does not affect the relation fields. The problem is specifically with the relation_fv_rs_* and their corresponding relation_to_ fields.

[shrsr]

@jasonjuenger Do you still see a diff on relation_fv_rs_tenant_mon_pol for the tenant resource after changing annotation to "orchestrator:ansible" or are you seeing a diff on the vrf/other resources and not the tenant?

[jasonjuenger]

Yes, I still see a diff on relation_fv_rs_tenant_mon_pol for the tenant resource after changing the annotation. See below:

  # aci_tenant.tenants["test"] will be updated in-place
  ~ resource "aci_tenant" "tenants" {
        id                            = "uni/tn-test"
        name                          = "test"
      ~ relation_fv_rs_tenant_mon_pol = "uni/tn-common/monepg-default" -> (known after apply)
        tags                          = []
        # (4 unchanged attributes hidden)
    }

[shrsr]

@jasonjuenger I was not able to reproduce the diff you're seeing at my end.
Can you please share the complete config with tfvars and state file without giving away other details?