Rethinking the start-up sequence #1055
Labels
status:Need Info
We believe we need more information about an issue from the reporting user to help, debug, fix
type:Enhancement
A proposed enhancement to the docker images
For background: I run a kubernetes-based JH cluster for my university (and a batchspawner based one, too), and have often had to struggle against the way these images are set up. That doesn't mean something is wrong, I just have tended to do lots of setup to integrate things. Combined with difficulties of incremental upgrades, I was wondering if I should try another strategy for some docker images. Maybe it's good to discuss here.
Summary: what about moving to a multi-phase setup (#787, but split out the different parts into multiple scripts, instead of the script re-executing itself), and the start scripts become very minimal: most things are done in hooks, instead. There are root hooks and user hooks, so the root part doesn't have to duplicate the user part. We try to make use of OS-level configuration, instead of doing it ourselves (e.g. NB_UMASK is currently set in jupyter_config.py - this should be a user hook).
Note that I'm not a docker expert - I have more background in sysadmining, but I've maintained our docker images for years now.
initial questions
jupyter lab
, without knowing how to do our other special setup? Seems not too hard to do, with the type of setup we have now - passing arguments to run through, default to starting jupyter.Example
I haven't really thought about this that much
init.sh
- are we root or not? root=root-setup.shroot-setup.sh
- read root hooks, then user-setup.sh $@user-setup.sh
- read user hooks, then jupyter.sh $@jupyter.sh
- do the option parsing, notebook/lab selection, etc. start jupyter. Right now this happens before the other starting wrapper, spread out across several files.We can configure user environment in different places:
/etc/profile.d
if we start via a login shellsource /opt/conda/bin activate
in profile.d or a user hook.I'm not sure if this "integrating with the OS" is a good idea - it's certainly not dockerish and may add in other subtle bus, but then again we are beyond normal docker use...
If any of the above sounds interesting, it's the kind of thing I can quickly hack on, but it would be good to have advice on the docker side.
The text was updated successfully, but these errors were encountered: