terraform-provider-bigip

terraform-provider-bigip copied to clipboard

Environment

• TMOS/Bigip Version: BIG-IP 16.1.1 Build 0.0.16 Final
• Terraform Version: 1.5.7
• Terraform bigip provider Version: 1.21.0

Summary

There are 2 configuration drifts on my virtual servers which appear in my terraform plan results. These drifts appear all the time, even if they are corrected by a terraform apply. This creates a constant loop with false change detection.

Steps To Reproduce

Steps to reproduce the behavior:

• Provide terraform resource config which you are facing trouble along with the output of it.

bigip_ltm_virtual_server resource:

resource "bigip_ltm_virtual_server" "main" {
  name                       = "/Common/xxxxxxx-domain-name"
  destination                = "192.168.1.10"
  port                       = 443
  ip_protocol                = "tcp"
  profiles                   = ["/Common/tcp", "/Common/http", "/Common/websecurity", "/Common/ASM_block_rule"]
  client_profiles            = ["/Common/clientssl"]
  server_profiles            = ["/Common/serverssl"]
  security_log_profiles      = ["/Common/splunk", "/Common/Log illegal requests"]
  policies                   = ["/Common/generic_asm_block_policy"]
  source_address_translation = "automap"
  pool                       = bigip_ltm_pool.main["xxxxxxx-domain-name"].name
  irules                     = ["/Common/default_f5_healthcheck"]
}

provider:

terraform {
  required_providers {
    bigip = {
      source  = "F5Networks/bigip"
      version = "1.21.0"
    }

    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }

  backend "s3" {
    encrypt = false
  }
}

Expected Behavior

I don't want to have any more false changes... But only when I made a change to the code.

Actual Behavior

The first fake change:

When I specify an ASM policy name in the list of security policies of the virtual server, there is a misinterpretation of the name if it has spaces... This creates false changes in the result of the terraform plan.

For example: "/Common/Log illegal requests" has spaces in the name.

The provider detects a change at each terraform plan even though there is none. This is very problematic when we want to check the real changes made to the infrastructure.

Example (70 fake changes at the end of terraform plan):

module.waf2.bigip_ltm_virtual_server.main["xxxxxxx-domain-name"] will be updated in-place
  ~ resource "bigip_ltm_virtual_server" "main" {
        id                         = "/Common/xxxxxxx-domain-name"
        name                       = "/Common/xxxxxxx-domain-name"
      ~ security_log_profiles      = [
          - "\"/Common/Log illegal requests\"",
            "/Common/splunk",
          + "/Common/Log illegal requests",
        ]
        # (18 unchanged attributes hidden)
    }
Plan: 0 to add, 70 to change, 0 to destroy.

You can see an example of a fake change for module.waf2.bigip_ltm_virtual_server.main["xxxxxxx-domain-name"] resource.

The second fake change:

The list of security policies of the virtual server must be ordered in alphabetical order.. why ?

For example if I have 2 security policies: ["/Common/splunk", "/Common/Log_illegal_requests"], I have a fake change detected on each terraform plan. If I order the list like this: ["/Common/Log_illegal_requests", "/Common/splunk"], I don't have any fake changes.

Example (70 fake changes at the end of terraform plan):

module.waf2.bigip_ltm_virtual_server.main["xxxxxxx-domain-name"] will be updated in-place
  ~ resource "bigip_ltm_virtual_server" "main" {
        id                         = "/Common/xxxxxxx-domain-name"
        name                       = "/Common/xxxxxxx-domain-name"
      ~ security_log_profiles      = [
          - "/Common/Log_illegal_requests",
            "/Common/splunk",
          + "/Common/Log_illegal_requests",
        ]
        # (18 unchanged attributes hidden)
    }
Plan: 0 to add, 70 to change, 0 to destroy.

You can see an example of a fake change for module.waf2.bigip_ltm_virtual_server.main["xxxxxxx-domain-name"] resource.

Hi,

Thanks for reporting. Added to the backlog and internal tracking ID for this request is: INFRAANO-1508.