Description of problem: If a loadBalancerIP is defined on the Service it should be associated to the created Load Balancer. However, that is not happening as the LB CRD can be missing the lb_ip field definition, consequently a new Floating IP, different from the one specified on the Service spec, is allocated to the Load Balancer. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Create a service with loadbalancerIP defined and pointing to an existing FIP, like: apiVersion: v1 kind: Service metadata: labels: run: demo name: demo namespace: default spec: ports: - nodePort: 31089 port: 80 protocol: TCP targetPort: 8080 selector: run: demo type: LoadBalancer loadBalancerIP: 172.24.4.73 2. Check the LB is associated to that loadBalancerIP 3. Actual results: Expected results: Additional info:
Verified on 4.6.0-0.nightly-2020-09-10-011413 over OSP13 (2020-09-03.2) with Amphora. (shiftstack) [stack@undercloud-0 ~]$ openstack floating ip create nova -c name -f value 10.46.22.94 $ cat svc_resource.yaml apiVersion: v1 kind: Service metadata: labels: run: demo name: demo namespace: test spec: ports: - port: 80 protocol: TCP targetPort: 8080 selector: run: demo type: LoadBalancer loadBalancerIP: 10.46.22.94 [stack@undercloud-0 ~]$ oc apply -f svc_resource.yaml service/demo created $ openstack floating ip list && openstack loadbalancer show test/demo Thu Sep 10 07:43:03 2020 +--------------------------------------+---------------------+------------------+--------------------------------------+--------------------------------------+------------------------------- ---+ | ID | Floating IP Address | Fixed IP Address | Port | Floating Network | Project | +--------------------------------------+---------------------+------------------+--------------------------------------+--------------------------------------+------------------------------- ---+ | 4a2d4733-4e54-4c68-9929-9e4320b9fede | 10.46.22.94 | 172.30.54.34 | 6ddde2cc-70f5-406e-9f41-e30e113b97aa | 0132543c-5a9c-4db7-8451-104e80fe0f4a | 9057d7bbe4fa4b5aace210967d5585 25 | | 66559ac5-9750-495c-ad64-277467200ff7 | 10.46.22.113 | 10.196.0.5 | 966d733a-b6b5-4e2a-b6af-c1dd1ccf8b71 | 0132543c-5a9c-4db7-8451-104e80fe0f4a | 9057d7bbe4fa4b5aace210967d5585 25 | +--------------------------------------+---------------------+------------------+--------------------------------------+--------------------------------------+------------------------------- ---+ +---------------------+--------------------------------------+ | Field | Value | +---------------------+--------------------------------------+ | admin_state_up | True | | created_at | 2020-09-10T11:41:24 | | description | openshiftClusterID=ostest-bwl6w | | flavor | | | id | dc0ff47d-2713-4051-8096-9558fb4876c9 | | listeners | 40b39e61-aaab-473b-8e58-52f2a9434ca2 | | name | test/demo | | operating_status | ONLINE | | pools | f46a9652-8199-43bd-a150-b2495b59cab3 | | project_id | 9057d7bbe4fa4b5aace210967d558525 | | provider | octavia | | provisioning_status | ACTIVE | | updated_at | 2020-09-10T11:43:09 | | vip_address | 172.30.54.34 | | vip_network_id | 6ba0a6fc-2f2b-4126-b0d7-ee125e97490e | | vip_port_id | 6ddde2cc-70f5-406e-9f41-e30e113b97aa | | vip_qos_policy_id | None | | vip_subnet_id | f57087c3-6e82-49c6-abb2-8c8d4e22dd79 | +---------------------+--------------------------------------+ (overcloud) [stack@undercloud-0 ~]$ curl 10.46.22.94 demo: HELLO! I AM ALIVE!!!
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 (OpenShift Container Platform 4.6 GA Images), 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-2020:4196