Short answer: There is no streamlined onboarding mechanism for JupyterHub access. I have to individually add people to the access control group in Keycloak.
Long answer: There is no streamlined onboarding for JupyterHub access, because it is not clear to me how many users the system can actually support. The primary limitation is the persistent storage attached to the individual JupyterLab server. Another issue is how to balance the cpu/mem limits for each server against the shared resources needed by the CE jobs.
We have the flexibility to optimize it to meet our needs, so we could choose to make the persistent storage very small and put tight constraints on the JupyterLab resources to discourage people from trying to run scientific workloads there; instead, they would use it as a graphical interface to the CE as we planned from the beginning.
I can lower the capacity and consider ways to make onboarding easier; similar to how we share the burden of CE user requests.
I would argue that if a researcher needs to do more serious work, we should direct them to the instructions for running locally on their own machine since it is not so hard to do and they will benefit from their own probably extensive CPU and memory. I’m hesitant to endorse third-party options directly.
Yeah, I do think that for the tutorial it would be a good idea. 1) because in the quickstart guide we give that option and 2) the user only has to learn how the CE interface works instead of also figuring out how to set up the notebook in their own laptop.
This has been proving to be the hardest step for someone not familiar with Jupyter notebooks.
I see what you mean. Another option is to downplay the Jupyter notebook in the quickstart and instead highlight a static step-by-step walkthrough of the equivalent Python script. The code snippets would be something you could copy-paste into an interactive Python session so that the learning effect would be the same as a notebook, and potentially better because of the deliberate transcription process (where of course the full script would be linked for convenience).
We have to calibrate our documentation to match our mental model of the typical CE user as we did while designing the system. The CE is not point-and-click simple, so we don’t have to make the documentation point-and-click simple.
I think what you suggest here is probably the perfect in-between. It’s just a copy-paste to put lines of code into a Jupyter notebook, if people want to go this way, but at least we wouldn’t have to provide the resource for that, since it would be very difficult to evaluate the needs
I like this idea too. Explaining the steps in the documentation itself might make people more prone to reading the steps, whereas the notebook invites them to just run it and see if it works.