Bug 2042976

Summary: Fully Populated Load Balancer creation with OVN provider leaves pools as PENDING_CREATE
Product: Red Hat OpenStack Reporter: Joaquín Veira <jveiraca>
Component: python-networking-ovnAssignee: Fernando Royo <froyo>
Status: CLOSED ERRATA QA Contact: Eran Kuris <ekuris>
Severity: medium Docs Contact:
Priority: medium    
Version: 16.2 (Train)CC: apevec, averdagu, gthiemon, lhh, ltomasbo, majopela, mbooth, mdemaced, scohen, tweining
Target Milestone: z3Keywords: Triaged
Target Release: 16.2 (Train on RHEL 8.4)   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: python-networking-ovn-7.4.2-2.20220302155430.75f38b0.el8osttrunk.noarch.rpm Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2055629 (view as bug list) Environment:
Last Closed: 2022-06-22 16:03:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2055629, 2082496    

Description Joaquín Veira 2022-01-20 12:54:20 UTC
Description of problem:
Creating a Fully Populated Load Balancer with OVN as provider successfully creates the LB but the pool stays in PENDING_CREATE state forever.

Version-Release number of selected component (if applicable):
RHOSP 16.2.1

How reproducible:

Send the fully populated request to the API in JSON format following https://docs.openstack.org/api-ref/load-balancer/v2/index.html?expanded=create-pool-detail,create-a-load-balancer-detail#creating-a-fully-populated-load-balancer


Steps to Reproduce:
1.
#!/bin/sh
 
set -e
 
subnet_id=$(openstack subnet show private-subnet -c id -f value)
 
TOKEN=$(openstack token issue -f value -c id)
OCTAVIA_BASE_URL=$(openstack endpoint list --service octavia --interface public -c URL -f value)
 
cat <<EOF > tree.json
{
    "loadbalancer": {
        "name": "lb1",
        "vip_subnet_id": "$subnet_id",
        "provider": "ovn",
        "listeners": [
            {
                "name": "listener1",
                "protocol": "TCP",
                "protocol_port": 80,
                "default_pool": {
                    "name": "pool1",
                    "protocol": "TCP",
                    "lb_algorithm": "SOURCE_IP_PORT",
                    "members": [
                        {
                            "address": "192.168.122.18",
                            "protocol_port": 8080
                        }, {
                            "address": "192.168.122.19",
                            "protocol_port": 8080
                        }
                    ]
                }
        }
        ]
    }
}
EOF
 
curl -X POST \
    -H "Content-Type: application/json" \
    -H "X-Auth-Token: $TOKEN" \
    -d @tree.json \
    ${OCTAVIA_BASE_URL}/v2.0/lbaas/loadbalancers


2. openstack loadbalancer pool list
3.

Actual results:
LB created but pool stays in PENDING_CREATE status

Expected results:
LB fully functional

Additional info:

Comment 1 Gregory Thiemonge 2022-01-20 13:16:03 UTC
Some notes:

the Octavia API passes the full load balancer object with the listeners and the pools to the ovn-provider. The ovn-provider creates only a load balancer, the other resources are not updated so they are stuck in PENDING_CREATE.

If the user delete the load balancer with cascade=True, it doesn't delete the associated pools and listeners (leaks in the DB).

ovn-provider should either implemented the creation of fully populated LB or throw an exception to deny the creation (UnsupportedOption or NotImplemented)

Comment 9 errata-xmlrpc 2022-06-22 16:03:23 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Release of components for Red Hat OpenStack Platform 16.2.3 (Train)), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:4793