Page History

General Assumptions

Single Application Catalog will exists in Airavata to be used by all the gateways.
Each gateway will be creating, updating, deleting, etc... their own application deployments in the supercomputers.
Each gateway will have ADMIN users who would do above tasks in the Application Catalog
Airavata ADMIN users will be able to view details entered through all the gateways using Airavata instance. They can also search and view application deployments;
E.g.:
- Search for all applications which are in turned-on state in all supercomputers
- Search for application deployments of specific gateway
If necessary Airavata ADMIN users will also be able to maintain application deployments across gateways.
Applications and workflows will always be deployed, created (workflows will be created using XBAYA), etc... prior to entering in the Application Catalog.

...

In Airavata there are two ways of executing experiments in supercomputers/ computational resources (Trestles, Stampede, Amazon EC2, Big Red II, etc…).
- Execute applications - Single submission experiments
- Execute workflows - Multiple node OR single node experiment
To execute experiment jobs of either above types; we rely on ‘Descriptors’ in Airavata to provide information required on application, application hosted supercomputers and input output parameters of the application.
There are three types of descriptors;
- Host Descriptors
  Specifies the application residing/hosting resource information. GRAM, GridFTP, Amazon EC2, etc….
- Service Descriptors
  Input and output parameter information for an application
- Application Descriptors
  Specifies executable location information, deployment location information, scratch locations of output files, meta data specific for the application, meta data specific for the deployment (location where the application is deployed in the resource), etc…

...

Create application includes many sub tasks in the Application Catalog. Creating an application instance extends to;

- Entering resource specific information such as;
  - Deployed resource/supercomputer information
  - Defining resource specific parameters such as application residing location
  - Queue information
  - Deployment information such as using MPI, GPU, Serial, etc…
Creating workflow consists;
- Enter workflow information & resources where the workflow will be executed
- Define workflow nodes and applications to be used at each nodes in the workflow
- Defining subsequent input and output files
Application & workflow creation in the catalog will be a gateway ADMIN task.
Applications and workflows can be created by cloning & importing existing applications and workflows.
Creating applications and workflows will not make them available for users to execute their experiments.

Application deployments and workflows which are CREATED will be published in order to be used by gateway users.
Publishing applications and workflows is a gateway ADMIN user level task.
At the time of publishing applications the system would validate
;
- Existence of at least 1 deployment of the application
- Existence of at least 1 application and resource level

...

...

- ...
At the time of publishing workflows system should validate;
- Existence of at least one application in the workflow
- Existence of at least one node in the workflow
- ...
User can search within created applications in order to publish by providing;
- Application ID/Workflow ID (Generate ID within Application Catalog)
- Application Name
- Resource
- Application User Group
- ...

Gateway users (ADMIN, normal) and Airavata ADMIN users will search/list applications and workflows for different purposes. when searching/listing for applications and workflows different keys can be used;
Some examples;

...

- Application ID/Workflow ID
- Application name/Workflow Name
- Resource
- By ON/OFF flag
- Status (CREATED & PUBLISHED)
- By the special application user groups
- ...
Gateway users or Airavata users may want to use above listing for auditing purposes.

...

Application/Workflow can be turned ON and OFF whenever required by the gateway or Airavata ADMIN users.
This functionality will be used when the application/workflow need to be temporarily unavailable for the users.
Applications/workflows which are published can be turned ON and OFF.
Turning ON and Off can be done at different levels. Such as;
- Resource level
- Application user group level
- Application level
When an application or a workflow is turned OFF from a certain level it needs to be turned ON from the same level as well.
- E.g.: When applications are turned OFF at resource level they cannot be turned ON individually; turning ON also will happen at resource level.

Airavata internal component can also query information from the Application Catalog. Orchestrator, Workflow Interpreter, GFac can query information required to formulate the tasks to be executed in the supercomputers.
Orchestrator will query Application Catalog to retrieve information required to submit single submission jobs into GFac. It will retrieve;
- Information on application residing resource
- Information on application specific parameters
- If the experiment didn’t specify resource Orchestrator will select a resource from Application Catalog
- …
Workflow interpreter will retrieve information required to submit jobs of the workflows.
- Retrieve information on applications to execute for each node
- Information on resources where applications are running
- Application version information

...

- ...
GFac will also use information stored in the Application Catalog
- Information on locations for input data files, output data files, error files and log files for each application
- Information on application versions and other information required for application execution
- Information to select the correct providers and handlers
- ...

...