Description of problem: It is very, very common for production environments to only allow access to the public network and not the associated public subnets. In that case, we fail to allocate a floating IP to the Loadbalancer service type. The reason why we fail is because our configuration revolves around passing the subnet id and retrieving the network id from that. It makes sense since in this way we get rid of the ambiguity of which of the public subnets were intended to be used. In practice this presents cloud policy issues. In order to fix it, we need to add a required option for specifying the network id instead and switch the subnet config option to being optional. How reproducible: 100% Steps to Reproduce: 1. oc run --image=kuryr/demo demo 2. oc expose dc/demo --port 80 --target-port 8080 --type LoadBalancer 3. oc get svc -o wide Actual results: No FIP is assigned to the demo service Expected results: There is a loadbancer FIP set by kuryr that can be reached Additional info:
This is fixed upstream, setting to POST.
Verified in version openstack-kuryr-kubernetes-controller-0.4.3-1.el7ost.noarch from puddle 20180502.1. Verification steps (with openshift): 1.- Make sure external_svc_net param is set with external network id in kuryr-config configmap (oc -n openshift-infra edit cm kuryr-config). 2.- oc new-project test 3.- oc run --image kuryr/demo demo 4.- oc scale dc/demo --replicas=2 5.- oc expose dc/demo --port 80 --target-port 8080 --type LoadBalancer service "demo" exposed 6.- oc get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE demo LoadBalancer 172.30.230.80 172.29.117.222,172.29.117.222 80:32440/TCP 19s 7.- Check a floating IP has been asigned for the load balancer: (overcloud) [root@undercloud stack]# openstack floating ip list | grep 172.30.230.80 | 03e9b5db-1792-4e57-9ece-f79cf8b5ad0c | 172.20.0.218 | 172.30.230.80 | 9d604dbe-e7e0-4e57-a85e-9dd0b4c9d49c | dbba197f-d28e-49be-9905-fde1fa67cd52 | 6c07532860e641989bacc5583275080a | 8. Check the floating IP is reachable: (overcloud) [root@undercloud stack]# curl 172.20.0.218 demo-1-5pn86: 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, 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/RHEA-2018:2086