JupyterHub incorrectly installs second load balancer
Summary
When installing JupyterHub via GitLab's k8s integration, a second (unnecessary) load balancer named proxy-public
is installed.
Original issue content
Multiple things about the install are broken:
- Install triggers the creation of a second load balancer, which is attached to Digital Ocean Kube cluster but not used, because the jupyter install uses the Ingress load balancer.
- Cannot change domain name before install, and adding a record to the ingress does not allow the domain to be changed, and a CNAME record breaks SSL with no way to tell Jupyter about it.
- Signing in with Gitlab redirects to the OAUTH url (https://jupyter.--load bal IP--.nip.io/hub/oauth_callback?code=&state=--state token--%3D%3D) which results in a 403 forbidden due to 'missing cookies' , checking the cookies for the site in firefox, no cookies have been created.
Steps to reproduce
Install JupyterHub, query the cluster for load balancers.
What is the current bug behavior?
proxy-public
load balancer is created on JupyterHub installation
What is the expected correct behavior?
No additional load balancers are created upon installing JupyterHub
Possible fixes
JupyterHub creates a second Load Balancer named proxy-public. I think it's part of JH helm config. We need to do something like this to stop creating second load balancer.
Edited by 🤖 GitLab Bot 🤖