Closed planetf1 closed 1 year ago
This seems to be the same issue as https://github.com/jupyterlab/jupyterlab/issues/10576
The reported issue there was that a service named 'jupyter' existed in the same namespace.
This is indeed the case in my environment - I have a load balancer service named 'jupyter' which has been present for years.
jupyter LoadBalancer nnn.nnn.nnn.nnn xxx.appdomain.cloud 8888:30777/TCP 66d
I'm guessing that the latest jupyter lab update has made some assumption when trying to retrieve a port name which is not set explicitly.
Deleting this service (and recreating with a new name) avoids this issue, and the jupyter pod then starts up.
For now, no plans to update docs. Hopefully if anyone else hits this issue they will find this issue.
I tried out the 4.1 charts (on OpenShift 4.12) (3 nodes, 16GB/4vCPU each)
The jupyter server fails to correctly start ie:
Full log from this pod posted to https://gist.github.com/planetf1/48f88a00770e3aa68496003e0ad78a76
Failure:
Investigating ... cc: @lpalashevski