Job Scheduling

The purpose of job scheduling is to take the start data that the user has sent from the API call and merge it with a template string that is returned from the job scheduling function.  Instead of starting a session immediately, the FastX server will execute this interpolated string and any output will be returned to the user.  FastX leverages this feature to allow admins to configure FastX to execute job schedulers like SLURM, MOAB, LSF etc to start sessions.

Note that in FastX terminology, Job Scheduling and Load Balancing are two different actions.

  • Job Scheduling is the act of creating a template string in place of the start command
  • Load Balancing is the act of choosing which server to execute the start data.

When integrating LSF (or equivalent), you will execute the template function (job scheduling) on the serverId returned (load balancing).  In this instance, where the session finally gets started is up to LSF

Built In Launchers

FastX ships with several built in Job Schedulers to simplify standard load balancing algorithms

Admin > Sessions > Launcher > Launcher

  • Start Immediately — default. Start the session immediately. No scheduling.
  • Docker — launch a docker container.
  • Custom — Use a custom Job Scheduler

Custom Launchers

Admins can create custom scheduling scripts. In FastX 4, the launcher script is a custom executable script that the admin writes. Set the following environment variables in $FX_CONFIG_DIR/fastx.env

  • LAUNCHER_SCRIPT=/path/to/script — custom launcher script
  • LAUNCHER_ARGS=--arg1,--arg2,--arg3 — comma separated list of launcher arguments
  • LAUNCH_AS_CURRENT_USER=true — (optional) run the script as the FastX user. By default runs as the logged in user.

Output

Any output will be shown to the user. If the output is a JSON object with a “result” parameter, the output will be interpreted as a start success command.

Script Input

The job scheduler script will send the following input to stdin as a JSON string.

{
  "socketFile": "/path/to/fastx-server/socket",
  "rootDir": "/usr/lib/fastx/4",
  "varDir": "/var/fastx",
  "configDir": "/etc/fastx",
  "localDir": "/var/fastx/local",
  "tmpDir": "/tmp",
  "uid": 1001,
  "gid": 1001,
  "homedir": "/home/username",
  "shell": "/bin/bash",
  "login": "username",
  "start": <start-object>
}

Pending Sessions

Sessions that have been scheduled but not yet connected back to the launcher are considered pending. Users cannot connect to a pending session. However there are a limited number of maintenance and information gathering actions (get info, terminate, purge) that a user can do on a pending session.