Thanks! SLURM Elastic Computing seems like it might do the trick. I need to try it out.
xCAT is interesting, too. It seems to be the HPC version of Salt'ed Cobbler. :) I don't know that it's so important for our problem. We have a small cluster for testing against the cloud, primarily. I could see xCAT being quite powerful for large clusters. I'm not sure how to explain the Unix user id problem other than a gmail account does not have a corresponding Unix user id. Nor do you have one for your representation on this mailing list. That decoupling is important. The actual execution of unix processes on behalf of users of gmail, this mailing list, etc. run as a Unix single user. That's how JupyterHub containers run. When you click "Start Server" in JupyterHub, it starts a docker container as some system user (uid=1000 in our case), and the container is given access to the user's files via a Docker volume. The container cannot see any other user's files. In a typical HPC context, the files are all in /home/<unix-user>. The "containment" is done by normal Unix file permissions. It's very easy, but it doesn't work for web apps as described above. Even being able to list all the other users on a system (via "ls /home") is a privacy breach in a web app. Rob