Interactive jobs using bypass
From EGEE-see WIki
Contents |
Introduction
gLite WMS supports interactivity through the Interactive job type. Interactive job starts the job executable as usual but instead of sending output into a file, it connects the job standard input/output over the network to the UI. This creates a real-time interactive connection between the user and the running job.
Usage
JDL for an interactive job is quite simple since there is no need to specify standard output, error and output sandbox:
JobType = "Interactive" ;
Executable = "job.sh" ;
InputSandbox = {"job.sh"} ;
Script used to test this functionality needs to read something from the standard input and write back to standard output:
#!/bin/sh echo "Welcome!" echo "Please tell me your name: " read name echo "That is all, $name." echo "Bye bye." read name2 echo "Go away, $name2." exit 0
Interactive job is submitted as usual but instead of returning a job ID and exiting, it starts listening for a network connection on a TCP port. When the jobs starts running on the WN it connects back to the UI allowing the user to communicate with the running job.
$ glite-wms-job-submit -a interactive.jdl Connecting to the service https://wms.phy.bg.ac.yu:7443/glite_wms_wmproxy_server ====================== glite-wms-job-submit Success ====================== The job has been successfully submitted to the WMProxy Your job identifier is: https://wms.phy.bg.ac.yu:9000/DixQFWseSalaFRgBIiRSqQ Interactive Session Listener successfully launched With the following parameters: - Host: grid1.irb.hr - Port: 21884 ========================================================================== *************************************** Interactive Job console started for: https://wms.phy.bg.ac.yu:9000/DixQFWseSalaFRgBIiRSqQ Please press ^C to exit from the session Pipe Name = /tmp/listener-aHapVRlyqNMWZoHofrwcIA.out *************************************** Floki Welcome! Please tell me your name: That is all, Floki. Bye bye. Go away, . *********************************** * INTERACTIVE JOB FINISHED * ***********************************
As can be seen from the job output, the communication is not quite as expected. Due to timing or buffering problems, glite-wms-job-submit starts reading input before it has displayed first part of the text. Also the second input is skipped and the program finishes. Running non-interactive jobs using this facility also shows problems of repeated and duplicated output.
Implementation
The communication pattern between the involved processes is quite complex as shown in the following image:
+--pipe--> glite-wms-grid-console-shadow --TCP--> glite-wms-pipe-input ----pipe--+
| |
terminal/user <==> glite-wms-job-submit v
^ job.sh
| |
+--pipe--- glite-wms-grid-console-shadow <--TCP-- glite-wms-pipe-output <--pipe--+
Before submitting the interactive job, glite-wms-job-submit creates a glite-wms-grid-console-shadow process listening on a port on the local machine. The listening hostname:port pair is then sent to the WMS together with the job. After that, glite-wms-job-submit starts passing information between the user's terminal (through standard input/output file descriptor) and glite-wms-grid-console-shadow (through a pair of named pipes created in /tmp). At the same time glite-wms-grid-console-shadow accepts a network connection from the WN and starts passing information from the network to the named pipe and vice versa (one process is created for input and one for output).
On the WN side, WMS jobwrapper first tries to download several executables from the WMS: glite-wms-job-agent, glite-wms-pipe-input, glite-wms-pipe-output and libglite_wms_grid_console_agent.so.0. Job executable is not started directly but by the glite-wms-job-agent. glite-wms-job-agent first creates two named pipes and connects them to glite-wms-pipe-input and glite-wms-pipe-output processes. These two connect back to the UI and start passing data between the named pipes and the network connections. Finally the job executable is started with its input and output connected to the previously created named pipes.
Implementation of the interactive job functionality in gLite is based on Condor Bypass. Condor Bypass works by intercepting arbitrary system calls (usually open, read and write) and forwarding them to a remote end (shadow) for execution. In the case of glite-wms-pipe-input and glite-wms-pipe-output, read and write calls are implemented to read and send data to the glite-wms-grid-console-shadow process over the network. Although gLite gives some basic interactivity between the user and the job, implementation is still having significant usability problems as shown by the example job.
