Hello all,
I can’t find any information in the various docs that indicate if the config is only loaded when the server is launched or if changes are updated to a running instance. Does JupyterLab work like Hub and only get config values when the service is started?
If that is the case, are the values inside one of the dockerstack images only overridable with a mounted volume, a docker commit, or via command line args?
Most configurables descend from:
… and yes, they generally only load their values at startup time. It’s possible starting them with --debug might make them watch sources and reload from the ground up, but watching files is kind of a performance and stability black hole, and can’t really be recommended.
Most don’t ship such a default config file for themself on the search path by default, and use their default values in various code.
However, when one application is configuring another application, and because “exactly one file is hell,” some specific “leaf” applications like server, notebook, and lab can be overridden piecemeal by individual packages with a file deployed in {sys.prefix}/etc/jupyter/{app}_config.d/{whatever}.json, as per jupyterlab enabling itself, though the exact mechanism there is a little more complex (lab itself can be the application, rather the server).
In the case of a container, all of the above are reasonable approaches to achieve an immutable deployment. For very specific cases, one could package and deploy a server extension that watched exactly one file (or external port or whatever) and applied the changes to the hot server application, and bake this into the container.
3 Likes
Awesome thank you for confirming for me, I was trying to save some cycles rebuilding all of the massively unreasonably sized images…but at least this gives me good enough reason to add some intermediary layers to simplify some of this crud.
Thanks again 