PTP/planning/remote

Evaluation of Remote Service Explorer for Remote Service Support

Background

The Need for Remote Compile, Launch and Debug

The current implementation of PTP (v1.0) provides basic support for the coding, compiling, launching and debugging of parallel jobs locally (the parallel machine). In a practical configuration, the development of parallel programs often involves three environments:

User desktop	: the user environemnt that supports coding and provids UI for compiling, launching and debugging.
Build environment	: the machine on which the program is to be build, which provides an environment with the same libraries and services available on the parallel machine.
Parallel machine	: the machine on which the program is executed.

We need to provide support for such configurations in PTP, which includes remote build, remote launch and foreseenably remote debug.

Configuration Alternatives

Actually, there are however three different possibilities in the actual configuration:

Local Project	: the user desktop physically holds the project and all codes of the parallel program in the local file system.
Remote Project	: the project and all codes are physically located on a remote machine (either a dedicated machine or one of the build machine or parallel machine).
Hybrid Project	: the user desktop physically holds the project (the configurations) but codes are physically located on a remote machine.

Local Project

In the case that the user desktop is the central location where the whole project is physically located, the following capabilities are required to support remote build, launch and debug:

Remote Build

1. The code must be first transferred to the build machine (possibly through project export).
2. The build command is invoked on the build machine.
3. The build log is transferred back to the local machine and update local models and views (problem view, marker view etc).
4. The binary is transferred back to the local machine.

Remote Launch & Debug

1. The runtime (e.g. ORTE) is transferred to the parallel machine, possibly also includes the debug runtime.
2. The binary is transferred to the parallel machine.
3. The command is invoked on the parallel machine to start the runtime.
4. The launch command is invoked on the parallel machine.
5. The user desktop can then control the execution and debugging of the
6. The stdio and stderr is trapped and send back to the user desktop.
7. Any output is transferred back to the user desktop.

Remote Project

In the case that a remote machine physically holds the project code, the following capabilities are required to support remote build, launch and debug:

Code Edit

1. The user environment access the project through remote file system.

Remote Build

1. The code should be transferred to the build machine (possibly through project export), if the build machine is different from the machine that physically holds the project.
2. The build command is invoked on the build machine.
3. The build log is transferred back to the local machine and update local models and views (problem view, marker view etc).
4. The binary is transferred to the remote machine that holds the project.

Remote Launch & Debug

1. The runtime (e.g. ORTE) is transferred to the parallel machine, possibly also includes the debug runtime.
2. The binary is transferred to the parallel machine from where the project is located, if different from build machine.
3. The command is invoked on the parallel machine to start the runtime.
4. The launch command is invoked on the parallel machine.
5. The user desktop can then control the execution and debugging of the
6. The stdio and stderr is trapped and send back to the user desktop.
7. Any output is transferred back to the machine where the project is located, if different from the build machine.

Hybrid Project

There's only quite minor differences between this case and that of a remote project.

Required Functionalities

Depending on the actual configuration, different functionalities are required:

Local Project

1. File transfer between local machine and remote machine
2. Execute commands on remote machines
3. Access services on the remote machine (standard TCP/IP)

Remote Project

1. Create project on remote file system
2. Transfer files between remote machines
3. Execute commands on remote machines
4. Access services on the remote machine (standard TCP/IP)

Hybrid Project

1. Create project folder or files on remote file system
2. Transfer files between remote machines
3. Execute commands on remote machines
4. Access services on the remote machine (standard TCP/IP)

Related Works

There are some on going works from both the Eclipse platform and the DSDP project that are relevant to us.

Open Issues

Resource management is being designed and developed in PTP, how does remote services support fits into the design remains to be discssed.