Is this really required here ? I was under the impression the web server already run user tasks in a container. all tasks run with the same unix id, but that is fine since isolation is provided by the container. did I get it right ?
I was thinking of an other approach, which is run the containers in the job, vs run the job in the containers. for example, you can wrap orted, so instead of having mpirun ssh host orted you could basically have ssh host run_in_container.sh orted that bring said, singularity might already do something similar, so it is likely a better fit. an other (far fetched) option is to submit two jobs into two clusters. - the first job started containers in the bare-bone cluster, each container runs slurmd and register itself in an elastic cluster with a per job unique resource. - the second job "naturally" runs under the elastic container when the container-ized resource is available, and then stop slurmd and the container. Cheers, Gilles On Monday, June 6, 2016, Ralph Castain <r...@open-mpi.org> wrote: > Thought about this some more, and I wonder if there isn’t a simpler > solution: > > * create a worker pool of userid’s that represents the maximum number of > simultaneous users you are willing to support. This could be very large, if > you want > > * when a worker id becomes available, pull the next email from the inbox, > assign it to that worker id, and submit that job to the scheduler for > execution > > * when the job completes, package the results/output and email them back > to the original sender. Then mark the worker id as available. > > You’ll still have security issues around the use of Docker, which is why > I’d recommend considering Singularity since it doesn’t require nor allow > privileged operations - and it doesn’t require integration with the > resource manager like Docker does. Singularity knows how to fully package > OMPI apps, so it is rather simple to automate the procedure for > “containerizing” the user’s app prior to submitting to the scheduler. > > HTH > Ralph > > > > On Jun 6, 2016, at 2:07 AM, John Hearns <hear...@googlemail.com > <javascript:_e(%7B%7D,'cvml','hear...@googlemail.com');>> wrote: > > Rob, I am not familair with wakari.io > > However what you say about the Unix userid problem is very relevant to > many 'shared infrastructure' projects and is a topic which comes up in > discussions about them. > Teh concern there is, as you say, if the managers of the system have a > global filesystem, with shared datasets, then if virtual clusters are > created on the shared infrastructure, or if containers are used, then if > the user have root access they can have privileges over the global > filesystem. > > You are making some very relevant points here. > > > > > > On 5 June 2016 at 01:51, Rob Nagler <openmpi-wo...@q33.us > <javascript:_e(%7B%7D,'cvml','openmpi-wo...@q33.us');>> wrote: > >> 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 >> >> >> _______________________________________________ >> users mailing list >> us...@open-mpi.org <javascript:_e(%7B%7D,'cvml','us...@open-mpi.org');> >> Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/users >> Link to this post: >> http://www.open-mpi.org/community/lists/users/2016/06/29369.php >> > > _______________________________________________ > users mailing list > us...@open-mpi.org <javascript:_e(%7B%7D,'cvml','us...@open-mpi.org');> > Subscription: https://www.open-mpi.org/mailman/listinfo.cgi/users > Link to this post: > http://www.open-mpi.org/community/lists/users/2016/06/29377.php > > >
