Open dwolfson opened 2 years ago
Agree, it would be good for this token to be stable once the chart is deployed.
The Jupyter token is generated at startup if it does not exist.
When the password is generated Jupyter adds it into a file in the ~/.jupyter directory called jupyter_notebook_config.py
This directory is not persisted in the current deployment, so the next time Jupyter starts the same thing happens.
Possible fixes include
Ideally both probably make sense.
There are also other authentication related settings, and general jupyer settings, so possibly an option to specify other overriding values could be useful, though more complex as they'd need to be merged in.
One additional thought to consider is that Jupyter allows a user defined password to be created using the token - perhaps we should do that to make it easier for users to login?
Yes - that's what I'm suggesting in the previous entry (second bullet) :-) Allowing the installer to specify a password is fine. I would not create a default password - so having an auto-generated token and persisting should be default.
Experimenting with the new approach to starting Jupyter in the development version of the Egeria-lab charts I found that each time the k8s cluster restarts, a new token is generated (and would thus have to be conveyed to users). This may be inconvenient for demo and non-developer usage. Suggest further investigation and discussion on Jupyter Server authentication approaches?