terraform-provider-bigip

terraform-provider-bigip copied to clipboard

Environment

• TMOS/Bigip Version: 15.1.5.1
• Terraform Version: 1.3.2
• Terraform bigip provider Version: 1.15.2

Summary

Error when creating virtual server resources that only differ in 1 attribute. In some cases, running terraform apply again without modification allows the failed resource to be created.

This is similar to this previous bug https://github.com/F5Networks/terraform-provider-bigip/issues/317

Steps To Reproduce

This is an example configuration that reproduces the behaviour. The only difference between the 2 resources is the ip_protocol. Creating this in the GUI does not cause an error.

resource "bigip_ltm_virtual_server" "server1" {
  name = "/Common/server1"

  destination = "192.168.1.1"
  port        = 8080
  ip_protocol = "tcp"
  vlans       = ["/Common/vlan1"]
}

resource "bigip_ltm_virtual_server" "server2" {
  name = "/Common/server2"

  destination = "192.168.1.1"
  port        = 8080
  ip_protocol = "udp"
  vlans       = ["/Common/vlan1"]
}

Expected Behavior

Both resources to be created successfully as they are different.

Actual Behavior

The first apply results in:

bigip_ltm_virtual_server.server2: Creating...
bigip_ltm_virtual_server.server1: Creating...
bigip_ltm_virtual_server.server1: Creation complete after 3s [id=/Common/server1]
╷
│ Error: HTTP 400 :: {"code":400,"message":"01070333:3: Virtual Server /Common/server2 illegally shares destination address, source address, service port, ip-protocol, and vlan with Virtual Server /Common/server1.","errorStack":[],"apiError":3}
│
│   with bigip_ltm_virtual_server.server2,
│   on f5.tf line 10, in resource "bigip_ltm_virtual_server" "server2":
│   10: resource "bigip_ltm_virtual_server" "server2" {
│
╵

Running apply again immeiately after successfully creates the previously failed resource.

With a different attribute being different

Similarly, in scenarios where the F5 may be a gateway to a network, the following configuration fails in a similar way but the 2nd apply doesn't succeed when the only difference is the VLAN:

resource "bigip_ltm_virtual_server" "gateway1" {
  name = "/Common/vlan1_gateway"

  destination = "0.0.0.0"
  port        = 0
  ip_protocol = "any"
  vlans       = ["/Common/vlan1"]
}

resource "bigip_ltm_virtual_server" "gateway2" {
  name = "/Common/vlan2_gateway"

  destination = "0.0.0.0"
  port        = 0
  ip_protocol = "any"
  vlans       = ["/Common/vlan2"]
}

The apply results in:

bigip_ltm_virtual_server.gateway1: Creating...
bigip_ltm_virtual_server.gateway2: Creating...
bigip_ltm_virtual_server.gateway2: Creation complete after 4s [id=/Common/vlan2_gateway]
╷
│ Error: HTTP 400 :: {"code":400,"message":"01070333:3: Virtual Server /Common/vlan1_gateway illegally shares destination address, source address, service port, ip-protocol, and vlan with Virtual Server /Common/vlan2_gateway.","errorStack":[],"apiError":3}
│
│   with bigip_ltm_virtual_server.gateway1,
│   on f5.tf line 1, in resource "bigip_ltm_virtual_server" "gateway1":
│    1: resource "bigip_ltm_virtual_server" "gateway1" {
│
╵

Running apply again results in the same error.

hi @petestroud there should be at-least source address to be diffferent for this config to apply on BIG-IP. working config.

resource "bigip_ltm_virtual_server" "server1" {
  name = "/Common/server1"
  destination = "192.168.1.1"
  port        = 8080
  ip_protocol = "tcp"
//  vlans       = ["/Common/vlan1"]
}

resource "bigip_ltm_virtual_server" "server2" {
  name = "/Common/server2"
  destination = "192.168.1.1"
  port        = 8080
  ip_protocol = "udp"
  source = "3.4.5.6/32"
//  vlans       = ["/Common/vlan1"]
}

Hi @RavinderReddyF5, the source address may need to be the same and that shouldn't prohibit the resource from being created by incorrectly detecting them as illegally sharing resources. The subsequent tf apply would surely fail on the first example if they were truly sharing attributes

Hi @petestroud fixed in v1.16.0 ,please open new issue if any problem seen