CiscoDevNet / terraform-provider-ise

Terraform Cisco ISE Provider
https://registry.terraform.io/providers/CiscoDevNet/ise/latest
Mozilla Public License 2.0
4 stars 1 forks source link

Idempotence issue with 'ise_trustsec_security_group' resource when using -1 for auto-generate #34

Closed grg1bbs closed 7 months ago

grg1bbs commented 7 months ago

ISE version = 3.2 p4 Terraform version = 1.6.6 Provider version = 0.1.11

Issue description When creating a Security Group using the 'ise_trustsec_security_group' resource with value = -1 to auto-generate the SGT number, the resource creates fine the first time. If the terraform apply is run a second time, however, it attempts to change the value and throws a client error.

Example TF code

resource "ise_trustsec_security_group" "sgt_corp_user" {
  name              = var.sgt_corp_user
  description       = "Corporate Users"
  value             = -1
  propogate_to_apic = false
  is_read_only      = false
}

Resulting client error

Terraform will perform the following actions:

  # ise_trustsec_security_group.sgt_corp_user will be updated in-place
  ~ resource "ise_trustsec_security_group" "sgt_corp_user" {
        id                = "ec71a9c7-2929-4914-a379-3d184de2d732"
        name              = "SG_Corp_User"
      ~ value             = 17 -> -1
        # (3 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.
ise_trustsec_security_group.sgt_corp_user: Modifying... [id=ec71a9c7-2929-4914-a379-3d184de2d732]
ise_trustsec_security_group.sgt_corp_user: Still modifying... [id=ec71a9c7-2929-4914-a379-3d184de2d732, 10s elapsed]
ise_trustsec_security_group.sgt_corp_user: Still modifying... [id=ec71a9c7-2929-4914-a379-3d184de2d732, 20s elapsed]
╷
│ Error: Client Error
│ 
│   with ise_trustsec_security_group.sgt_corp_user,
│   on trustsec_elements.tf line 3, in resource "ise_trustsec_security_group" "sgt_corp_user":
│    3: resource "ise_trustsec_security_group" "sgt_corp_user" {
│ 
│ Failed to configure object (PUT), got error: HTTP Request failed: StatusCode 400, Message: Validation Error - Illegal values: [illeagal sgt value:
│ sgt value cannot be changed in 'auto-generated' mode], {
│   "ERSResponse" : {
│     "operation" : "PUT-update-sgt",
│     "messages" : [ {
│       "title" : "Validation Error - Illegal values: [illeagal sgt value: sgt value cannot be changed in 'auto-generated' mode]",
│       "type" : "ERROR",
│       "code" : "Application resource validation exception"
│     } ],
│     "link" : {
│       "rel" : "related",
│       "href" : "https://ise32-3.ise.trappedunderise.com/ers/config/sgt/ec71a9c7-2929-4914-a379-3d184de2d732",
│       "type" : "application/xml"
│     }
│   }
│ }

Expected behaviour If possible, the provider should exempt the "-1" value from being seen as a change in state. You should be able to run the apply multiple times without an error.

kuba-mazurkiewicz commented 7 months ago

hey @grg1bbs ,

I was playing around with this sgt value -1 and there are a lot of complications with this. Once you create resource with value =-1 then this resource cannot be modified, and this object on ISE is getting random value assigned. That's why you are getting plan showing that update is required to change value from 17 to -1.

The easiest solution is to add following block to your TF code:

resource "ise_trustsec_security_group" "sgt_corp_user" {
  name              = var.sgt_corp_user
  description       = "Corporate Users"
  value             = -1
  propogate_to_apic = false
  is_read_only      = false

  lifecycle {
    ignore_changes = [value]
  }
}

This way running terraform plan or apply second time will work fine:

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Let me know if this is sufficient solution for you.

grg1bbs commented 7 months ago

Hi @kuba-mazurkiewicz ... of course, I forgot about using the lifecycle block for that. That's a viable workaround. Another workaround I was using was just setting a static value, which is probably more likely for a large organization anyway to ensure no SGT overlap across environments.