-
Bug
-
Resolution: Done
-
Normal
-
4.12
-
Quality / Stability / Reliability
-
False
-
-
1
-
Moderate
-
None
-
None
-
None
-
OSDOCS Sprint 229, OSDOCS Sprint 230
-
2
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Description of problem:
Testing loadBalancerClass, if --no-share is configured on the external network, Openshift is not able to gather any subnet matching the floating-subnet-tags:
With below cloud-provider-config:
config: |
[Global]
secret-name = openstack-credentials
secret-namespace = kube-system
region = regionOne
ca-file = /etc/kubernetes/static-pod-resources/configmaps/cloud-config/ca-bundle.pem
[LoadBalancer]
floating-network-id=03c0b9b2-5994-4611-a7dd-a95df903c2f9
[LoadBalancerClass "class1"]
floating-network-id=502d115b-d375-4923-b0bc-3cf8d6145e03
floating-subnet-id=9875edb3-9e4d-4332-b25f-5ee18b22b05d
[LoadBalancerClass "class2"]
floating-network-id=82e95b2c-7488-47c2-94bf-30ee8a69da91
floating-subnet-tags="class2tag"
[LoadBalancerClass "class3"]
floating-network-id=82e95b2c-7488-47c2-94bf-30ee8a69da91
floating-subnet="external_subnet3"
The apply of below manifest:
apiVersion: v1 kind: Service metadata: name: udp-lb-class2-svc namespace: udp-lb-class-ns annotations: loadbalancer.openstack.org/class: class2 labels: app: udp-lb-class-dep spec: ports: - port: 8083 targetPort: 8081 protocol: UDP selector: app: udp-lb-class-dep type: LoadBalancer
Is creating the loadbalancer but not attaching the svcIP to [floating-network-id=82e95b2c-7488-47c2-94bf-30ee8a69da91, floating-subnet-tags="class2tag"]. The subnet is not visible on the tenant, but by admin it is possible to access it:
(overcloud) [stack@undercloud-0 ~]$ o subnet list --network nova_fake --tag class2tag +--------------------------------------+------------------+--------------------------------------+-------------+ | ID | Name | Network | Subnet | +--------------------------------------+------------------+--------------------------------------+-------------+ | 10939f36-88ed-4e8d-a438-c2db1ae6dd09 | external_subnet2 | 82e95b2c-7488-47c2-94bf-30ee8a69da91 | 10.2.0.0/24 | +--------------------------------------+------------------+--------------------------------------+-------------+
The same is working when modifying the external network with --share and re-load the manifest.
Version-Release number of selected component (if applicable):
4.12.0-0.nightly-2022-10-10-015203 and RHOS-16.2-RHEL-8-20220804.n.1
How reproducible: Always
Steps to Reproduce:
1. Update cloud-provider-config
2. Load Manifests
Actual results: The FIP is not assigned to the LB.
Expected results: The FIP is successfully assigned.
Additional info: This behaviour is coming from openstack so we should at least document it so customers can request to configure the external network with the --share flag