JupyterHub Singleuser Port Routing Issue After Restart

[IMSUVEN]

Bug description

When customizing the singleuser port (e.g., setting it to 9999), the routing works correctly, directing traffic to port 9999. However, after a JupyterHub restart, the routing becomes erroneous and redirects to port 8888 instead.

How to reproduce

1. use a custom singleuser port (e.g., 9999) in jupyterhub.
2. Start Jupyter notebook and verify that the routing works as expected.
3. Restart JupyterHub.
4. Observe that the routing now incorrectly directs to port 8888 instead of the custom port (9999).

Expected behaviour

After a JupyterHub restart, the routing should continue to direct traffic to the custom singleuser port specified during configuration.

Actual behaviour

After a JupyterHub restart, the routing that was previously working correctly (directing traffic to the custom singleuser port, e.g., 9999) becomes erroneous. Instead of continuing to route to the specified custom port, it now incorrectly redirects to port 8888.

Your personal set up

• Deployment Method: zero-to-jupyterhub-k8s
• Chart name: jupyterhub
• Chart version: 3.2.1
• Chart config: singleuser.profileList[0].port=9999

Others

1. Observation:

   • After starting a JupyterHub singleuser pod, the database (servers table) correctly records a port value of 9999.
   • However, upon restarting JupyterHub, this port value is changed to 8888 in the database.
   • Simultaneously, the configurable-http-proxy receives a request to modify the routing to port 8888.
   • Eventually, JupyterHub becomes unable to connect to the singleuser pod via port 8888, leading to the cleaning of the singleuser pod.

2. Hypothesis:

   • The bug seems to occur during JupyterHub's initial startup, where it incorrectly resets all singleuser routes to port 8888 without referencing the port settings stored in the database.

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[IMSUVEN]

It seems related to this

kubespawner/kubespawner/spawner.py

Lines 1924 to 1959 in becea53

	def _get_pod_url(self, pod):
	"""Return the pod url
	Default: use pod.status.pod_ip (dns_name if ssl or services_enabled is enabled)
	"""
	if self.get_pod_url:
	# custom get_pod_url hook
	return self.get_pod_url(self, pod)
	if getattr(self, "internal_ssl", False):
	proto = "https"
	hostname = self.dns_name
	elif getattr(self, "services_enabled", False):
	proto = "http"
	hostname = self.dns_name
	else:
	proto = "http"
	hostname = pod["status"]["podIP"]
	if isinstance(ipaddress.ip_address(hostname), ipaddress.IPv6Address):
	hostname = f"[{hostname}]"
	if self.pod_connect_ip:
	hostname = ".".join(
	[
	s.rstrip("-")
	for s in self._expand_user_properties(self.pod_connect_ip).split(
	"."
	)
	]
	)
	return "{}://{}:{}".format(
	proto,
	hostname,
	self.port,
	)