Setting the user explicitly in ContainerConfig.yaml

[psychemedia]

Thus far, SSU appear to have a preference for containers built on the official Jupyter stack, or in line with it. So a consequence of this is that if they make assumptions about the user account, they assume jovyan and home directory /home/jovyan.

I appreciate you want to provide a robust way of building images for OU use, but eg during development, or in the general (default) case of folk running JupyterHub with its default expectations, it might be advisable to allow a config script to define at least the ou-user or jovyan user (which could be a boolean). The more useful general case would be to allow a user: element in the ContainerConfig.yaml file, with default ou-user, mapping to a corresponding environment variable.

In the official Jupyter stack, they have to date conventionally referred to $NB_USER (I forget offhand if this is also set as an environment variable?). It might make sense to map a config user value to $NB_USER to preserve this convention in case other things rely on it, although the implied semantics of $NB_USER is a bit off in the simple/no notebook server app case. A $USER or $JUPYTER_USER variable is more general but breaks at least informal Jupyter conventions.

[mmh352]

Unfortunately this cannot be supported. The reason being that in order for the containers to play nicely with each other when deployed via JupyterHub on k8s, the user and home directory have to follow specific rules. Allowing a user: setting would mean that the behaviour when running online would differ from the behaviour when run locally. This would make maintenance and debugging a painful experience.

[psychemedia]

Hmm... not sure I understand?

Why can't I use this tool to build containers for local use, or eg for someone running a JupyterHub with an expectation of /home/jovyan.

Looking at the Dockerfile or other generated files doesn't seem to preclude using jovyan?

My immediate concern is containers that use the jovyan user because we have lots of documentation out there for local install predicated on that; plus last time I chatted to SSU, they also had a strong preference for jovyan because it means less debug on anything off-the-shelf that assumes it.

For the next presentation of modules I work on, it's likely that I will need containers running under the jovyan user in case (partly because VLE updates are such a hassle to get through and get retested by LDS), in part because teaching and learning materials may refer to jovyan and updating those could be time consuming. I can edit the Dockerfile or branch the code to change ou-user to jovyan, dead simple. Even just adding

ARG USER=ou-user
ENV USER=${USER}
ENV NB_USER=${USER}

to the Dockerfile template would let me just use ou-container-builder as a Dockerfile generator and then I could override the user in a manual build process by passing --build-arg USER=jovyan (or if you hook up something around environment variables, maybe -e USER=jovyan).

Depending on how auth etc ends up working, it's also not unimaginable to consider students getting an oucu user account with things set up by a container start/setup process setting up a user on first run according to a passed in environment variable.

[psychemedia]

In passing, there are also various module teams doing things in production that may use of the shelf Jupyter warez / defaults and they may be building up debt around jovyan. That's not to say that couldn't be addressed at some point, but during development / production, a route to jovyan when it comes to development and testing of containers could be useful.

If things refer to $NB_USER/$USER/$JUPYTER_USER etc rather than a user name literal, it shouldn't matter anyway if the user variable is appropriately set? (I really hate hard-wired literals! ;-)

[mmh352]

The reason for the inflexibility is as follows:

• The toolchain is designed for building containers that work on the OU's JupyterHub on k8s and locally. At this point no other use-cases are being considered. Long-term deploying to IT's solution or SSU's local JH installation may also be considered, but only when that is actually technically possible from their end.
• In JupyterHub on k8s all containers share the same mount location for the user's persistent storage. This means it is not possible to have one container mount the persistent storage at /home/ou-user and another at /home/jovyan.
• In JupyterHub on k8s each user is allocated one persistent storage, which is shared across users. To ensure that containers do not trample over each other, there has to be a fixed rule for where in the persistent storage a container may write stuff and this is in the $CODE-$PRESENTATION folder inside of /home/ou-user.

Because the technical constraints are essentially out of my control, it is impossible to support requirements that do not play nice with those constraints.

A few further notes:

• Regardless of how the user auth is set up, the username within each container is always the same for all users (because it is defined at image build time, not at container run time).
• If you want the TM129 21J containers to run in the JupyterHub on k8s installation, then your containers will have to follow the constraints 2&3 defined above. The reason the 21B container can run as is, is because it is the only container running in that installation, but that will not be the case for the 21J presentation.
• There is no need to use the ou-container-builder, only that the constraints 2&3 are observed. That is, for example, how the S397 container runs. That is a custom build, but it follows the persistent-directory rules, so it can be supported.

[psychemedia]

Okay, so I need to clarify:

• the container I built for 21B for deployment by you won't work as is from 21J? This is really important to know, because it would require a sweep of all the materials looking for jovyan references, or move to the SSU server.

• it seems that there is an assumption of one JupyterHub to rule them all, rather than one JupyterHub per module/course, which is what I think some institutions do? (Eg from the existence of https://github.com/yuvipanda/hubploy, I wonder if Berkeley run separate JupyterHubs? But I guess that then causes issues about how you create a single volume for a student that you can mount to different JupyterHubs for the different courses they are on?) I'm not sure what the SSU or IT take is on this or whether due consideration has been made about the pros and cons of each approach (eg taking into account that modules are isolated and have different presentation patterns, that students defer on a module or may be on several modules at once, that students may want unified storage or be happy with per module storage, etc). Given the OU module is still dominated by module team fiefdoms, the one-jupyter-hub-per-module (or even per-module-per-presentation) seemed to for that structure and potentially gave module teams ownership of their environment isolated from everyone else.

• by "the JupyterHub on k8s installation", I assume you mean "the mmh352 JupyterHub on k8s installation", rather than the "the SSU JupyterHub on k8s installation" or "the IT JupyterHub on k8s installation", or "an arbitrary zero-to-JupyterHub on k8s installation"? I'm trying to understand what gets set where and why. And whether the setting is fixed or could be set via a parameter (and how/where that parameter would get set in turn). I imagine a lot of set up is around the UID, which we can take out of the equation as long as we agree on UID. So:

  • is the username required just to set the mount path, or for other reasons / in other places as well? I get that currently the user is baked in at image build time, but I don't see a reason why you couldn't in principle create a user with a customised name on a container's first run, with the name set from an ENV variable set via the container invocation, although I guess there could there be a chance for a race trying to mount the volume onto the path before creating the user inside the container that creates the path? But that's probably a red herring for now.
  • Re: the fixed username in the current deployment, is that something that is set as a literal value at a single point in the k8s config (as the volume mount point, maybe?) and that same setting applies to everything it creates?
    • is there any way that name can be set from a variable? (I've deliberately avoided spending time learning k8s because I don't want to end up running deployments, so apologies for my ignorance...)

[mmh352]

Moved this over into discussion #28.