-
Notifications
You must be signed in to change notification settings - Fork 801
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support subdomain_host (CHP needs --host-routing) #3548
Conversation
Can we add a couple of fields to the schema in hub.config that have significant consequences (with It probably makes sense to have a prose docs section on enabling this and the consequences. |
639c3e1
to
9658c24
Compare
Co-authored-by: Erik Sundell <[email protected]>
Can you think of an easy test we can add? |
If we just want a really simple test, I think we can start a cluster with subdomains enabled and make some requests to the cluster ip setting the Host header to the expected domain, e.g. # server_url from hub api will have the user's domain in it when subdomains are enabled
# server_url = "http://user.subdomain:port/user/name"
user_host = urlparse(server_url).netloc
user_path = urlparse(server_url).path
requests.get(f"http://{proxy_ip}:{port}{path}", headers={"Host": user_host}) Or if we can expose a localhost port to the service, we could use |
Thanks for the suggestion- I've added a test using the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Looks like it works. Anything more you want to add?
No, I think this is good enough! |
jupyterhub/zero-to-jupyterhub-k8s#3548 Merge pull request #3548 from manics/subdomain-host
The JupyterHub v5 upgrade doc says
which sounds like a strong recommendation. This is not currently supported by Z2JH as CHP needs the
--host-routing
flag. Since CHP is not managed by JupyterHub this isn't automatically configuredhttps://github.com/jupyterhub/jupyterhub/blob/ab43f6beb8571e2b831801089d61144b15951b85/jupyterhub/proxy.py#L738-L739
https://discourse.jupyter.org/t/user-subdomains-oauth-state-missing/29328/4
The main downsides of using
hub.config.subdomain_host
as the condition instead of a dedicated parameter such ashub.subdomainHost
(analogous tohub.baseUrl
qhich also requires configuring multiple chart manifests) are it's not part of the schema so won't appear in the generated chart documentation, and it also adds dependencies across manifests withhub.config
which I don't think we have, so this increases the maintenance complexity.