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
No FIP is assigned to the demo service
There is a loadbancer FIP set by kuryr that can be reached
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.