Hosting A Tool on VO Resources

VO hosted resources are run on Linux based systems. In order for us to host a tool on our cloud infrastructure, we will need to be provided with the following:
 - A brief document with a tool description and instructions for verifying correct functionality
 - The base OS and version you need installed
 - An ansible script to address installing the appropriate packages, configuring and setting up the environment for the tool
 - Optionally, an OpenStack image may be provided - however we will still need the above items to be made public for repeatability purposes.

Hosting A Tool on Non-VO Resources

The VO Active Resources feature does support using outside servers, which the tool provider would be responsible for maintaining. However as a matter of policy in keeping with the goals of public repeatability of experiments, we still require the same information as tools we host on our own infrastructure (see above).

Configuring a Server for VO Use

The VO runs commands on the remote server via SSH commands. For this the server needs:
- a publicly accessible IP address (or at least accessible to the 129.59.*.* network)
- ssh running on port 22 and configured for keypairs
- a user account for the VO to use with the appropriate permissions to run the scripts for the tool
- a working folder for the VO to use when running the tool
- the VO ssh public key added to the user's authorized_keys file
This key is:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDYbDxo8GXpT+qh4A6GVM9iaOYXdVbaTJthyBdHlAkAvrQyqQ51MShHF4gBquyXSfhndbk+lDJBtFEW3c5bAi3SeFALKSaG9ECGQa9Rw29PPqCRJEEM8iuuJck/WzjZupCAGwZSUQRKADEUQ3sLQ4MSqWMXWuWSzXtTTMvfXI1bn9QJqQYXNp614iSfOAKgr5Pw0x9+szpD/zjLXiT941XpBOhN/r6vQcqnWzK9M97+huoP07MTBEmoL4G+oJwIgMJW0Xuls/dEb1dKDGOSy4ITg4aH1Wnz1KV+PM9OysZL9yf8Ul6tkkQB4UQ96+M/uLPuViO1ItpThq1a2b2oOo7x root@votest1

Alternatively, you can duplicate our authorized_keys file from http://cps-vo.org/node/24814 on the server, which will grant access for the VO as well as several of our developers in case assistance is needed with the server.

If your tool provides a graphical user interface for real-time feedback while it's running, it must be served over SSL with a valid certificate signed by a certificate authority (no self-signed certs, which means it must also have a DNS entry), and the URL must be accessible by the VO.

When a tool provider wishes to include a new tool on the VO, they must submit their tool for review and testing at https://cps-vo.org/node/29837. Once the VO team has had a chance to verify correct functionality with the VO, they will enable the tool for the site. Requests to update an existing tool may be made in the same manner.

Working Folder Structure

When a resource is launched by the VO, it will erase the working directory containing any files and folders that remain from the last time it executed on the server. It then recreates the folder structure each time as follows, inside the defined working directory:
- bin - the bin.tar.gz file is unzipped each time to create this folder. This contains all the scripts necessary to manage an active resource.
- inputs - each defined input will be stored inside a folder matching it's name in this folder upon form submittal.
- outputs - The VO will check this folder after stop for outputs to be returned to the user, typically via storage on the VO.
- pids - This folder is checked for any files to indicate if another resource is already running on the server before it launches a new one. Typically the start.sh script will store process IDs in here, and then iterate through them during stop.sh to cleanup processes. It should erase the pid files when complete so the VO will know nothing is running anymore.

The following files contain examples allowing you to see how inputs are saved into their folders (some are empty if not required!) and how PIDS are tracked.

Example working directory during a running active resource: running_working_folder.tar.gz
Example working directory for a stopped active resource: stopped_working_folder.tar.gz