destruction of listener not possible with terraform

[celinesantosh98]

Description of the enhancement

I have an infrastructure with load balancer, listener with a target group (pool), and backend member. So while creating it using terraform it first creates load balancer, backend group (pool), listener, backend member.
while destroying it , it destroys in reverse order. But it's not able to destroy listener before pool . it gives me this error

Error: unable to delete ListenerV3 d12bfa4a-79d8-480d-a6cd-27cbd03255bf: Expected HTTP response code [202 204] when accessing [DELETE https://elb.eu-de.otc.t-systems.com/v3/dcaf879e2fb94c1d86cc56fe45288baf/elb/listeners/d12bfa4a-79d8-480d-a6cd-27cbd03255bf], but got 409 instead
│ {"error_msg":"pool 7f432fce-85db-4f80-a7ea-ecb275d92ec0 is using this listener","error_code":"ELB.8907","request_id":"02d69056be68b798c631a4c481cf88c5"}

so each time I go to the open Telekom cloud console and delete listeners from there then again run terraform destroy to delete rest of the resources.

please suggest a way to solve this

thanks in advance.

[artem-lifshits]

Hello @celinesantosh98 please provide configuration that causes the error.

[celinesantosh98]

TO CREATE LOAD BALANCER
resource "opentelekomcloud_lb_loadbalancer_v3" "lb_1" {
name = var.elb_name
subnet_id = opentelekomcloud_vpc_subnet_v1.subnet_1.subnet_id
network_ids = [opentelekomcloud_vpc_subnet_v1.subnet_1.id]
ip_target_enable = true
availability_zones = var.listener_az
public_ip {
bandwidth_name = var.listener_public_ip_bandwidthname
ip_type = var.listener_public_ip_type
bandwidth_size = var.listener_public_ip_bandwidth_size
bandwidth_share_type = var.listener_public_bandwidth_share_type
}
}

TO CREATE TWO LISTENER ONE FOR HTTP AND HTTPS
resource "opentelekomcloud_lb_listener_v3" "listener_1" {
name = var.elb_listener_name
loadbalancer_id = opentelekomcloud_lb_loadbalancer_v3.lb_1.id
protocol = var.elb_listener_protocol
protocol_port = var.elb_listener_port
default_pool_id = opentelekomcloud_lb_pool_v3.pool.id
advanced_forwarding = true
sni_match_algo = var.elb_listener_sni_match_algo
lifecycle {
create_before_destroy = true
}
insert_headers {
forwarded_host = true
}
}

resource "opentelekomcloud_lb_listener_v3" "httpslistener_1" {
name = var.elb_listener2_name
loadbalancer_id = opentelekomcloud_lb_loadbalancer_v3.lb_1.id
protocol = var.elb_listener2_protocol
protocol_port = var.elb_listener2_port
default_pool_id = opentelekomcloud_lb_pool_v3.httpspool.id
advanced_forwarding = true
sni_match_algo = var.elb_listener_sni_match_algo
default_tls_container_ref = opentelekomcloud_lb_certificate_v2.certificate_1.id
lifecycle {
create_before_destroy = true
}
insert_headers {
forwarded_host = true
}
}

CREATE POOL AND MEMBER FOR EACH LISTENER
resource "opentelekomcloud_lb_pool_v3" "pool" {
name = var.elb_pool_name
loadbalancer_id =opentelekomcloud_lb_loadbalancer_v3.lb_1.id
lb_algorithm = var.elb_algorithm
protocol = var.elb_pool_protocol
session_persistence {
type = var.elb_pool_session_persistence
persistence_timeout = var.elb_pool_persistence_timeout
}
}

resource "opentelekomcloud_lb_pool_v3" "httpspool" {
name = var.elb_pool2_name
loadbalancer_id =opentelekomcloud_lb_loadbalancer_v3.lb_1.id
lb_algorithm = var.elb_algorithm
protocol = var.elb_pool2_protocol
session_persistence {
type = var.elb_pool_session_persistence
persistence_timeout = var.elb_pool_persistence_timeout
}
}
resource "opentelekomcloud_lb_member_v3" "member" {
name = var.elb_member_name
pool_id = opentelekomcloud_lb_pool_v3.pool.id
address = opentelekomcloud_waf_dedicated_instance_v1.wafd_1.service_ip #dwaf
protocol_port = 80
}

resource "opentelekomcloud_lb_member_v3" "member2" {
name = var.elb_member_name
pool_id = opentelekomcloud_lb_pool_v3.httpspool.id
address = opentelekomcloud_waf_dedicated_instance_v1.wafd_1.service_ip #dwaf
protocol_port = 80
}

[artem-lifshits]

Looks like there's a flaw in API which breaks terraform dependency graph.
Related ticket: https://jira.tsi-dev.otc-service.com/browse/ONS-11371

[dlliondeer]

We stumbled at the same problem.
But it does not seem to be a flaw with the terraform depency graph, because terraform wants to destroy the listener at the correct time, but OTC is giving the Error "pool is using this listener". This Error-message does not come from Terraform, but from OTC.
Since you can delete the listener in the OTC console, the Error-message is not correct. Otherwise the the console should give the same Message!

Here is our Error-message:

│ Error: unable to delete ListenerV3 1e2a60f9-e91d-470e-934b-c9e49f301887: Expected HTTP response code [202 204] when accessing [DELETE https://elb.eu-de.otc.t-systems.com/v3/1947dfb57bc14d28aeb7b0982a30a56d/elb/listeners/1e2a60f9-e91d-470e-934b-c9e49f301887], but got 409 instead
│ {"error_msg":"pool d369cbed-210c-4842-b974-a665f0164697 is using this listener","error_code":"ELB.8907","request_id":"b793f9ada223ede44cd360ad5b0b1964"}

Is there already a workaround without deleting the listener manually?

BTW. this does not happen with the Shared Loadbalancer, it only happens with the Dedicated Loadbalancer

[artem-lifshits]

Answer from R&D:
It is hard to change current API, but we can provide a new API
Demand to introduce new API: https://jira.tsi-dev.otc-service.com/browse/OTCPR-11918
Initial ticket: https://jira.tsi-dev.otc-service.com/browse/ONS-11371