Comment 8 for bug 1868062

Hi George,

I managed to overcome the problem and I wan to share the solution and the issues I faced:

1. The original problem was an outcome of missing security groups. Being more specific, Octavia Load Balancer could not communicate with kubernetes-master nova instances. The reason was that kubernetes-master were missing a security group (or rule from their existing groups depending on the design you want to follow) to allow ingress traffic to port 6443. As a result, despite being in the pool of the Load Balancer, the Load Balancer could not communicate with them.

2. I could use kubectl from my Juju jumphost because I was hitting Load Balancer VIP (this IP is written in .kube/config) and the Load Balancer could not speak with kubernetes-master instances.

My solution was to add a new security group to kubernetes-master instances to allow INGRESS to 6443 port from the private network I am using for the Juju units.

3. Another issue I faced was the following: During my tests I tried to use option manage-security-groups=true. But this cannot work if the provided OpenStack credentials are belonging to a member of a project. The reason is that the charm code tries to apply a security group to the OpenStack port which represent the Load Balancer VIP. This cannot be done from a member, thus, the code receives an error.

My solution to the problem above was to manually do the command from my admin user, comment out the line in the charm code, restart the juju agent of openstack-integrator and apply a change to a config option to trigger the update-config action.