Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

General Assumptions

  1. Single Application Catalog will exists in Airavata to be used by all the gateways.

  2. Each gateway will be creating, updating, deleting, etc... their own application deployments in the supercomputers.

  3. Each gateway will have ADMIN users who would do above tasks in the Application Catalog

  4. 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.

Existing Descriptors

 

  1. 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 experiments

 

  1. 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.

  2. 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…

Introduction - Application Catalog

 

  1. So what is more with Application Catalog? With application catalog user will be able to;

 

    • Store same set of information as with descriptors

    • Have number of new API methods to access and manage the applications as required

      • Create Application

      • Publish Application

      • Search/List Application

      • Update Application

      • Clone Application

      • Import Application

      • Delete Application

      • Turn On/Turn Off Application

    • Read from Application Catalog  - Other components will read from the Catalog in order to get relevant information required for experiments.

 

  1. In descriptors we have same set of parameters captured for clouds, supercomputers irrespective of the necessity. With the Catalog ‘the not required parameters’ will be ignored when creating, updating application information.

  2. Airavata components; Orchestrator, Workflow Interpreter & GFac will connect to Application Catalog to obtain information required for executing jobs at resources.

  3. Back-end services of Application Catalog. These will be automated services which would run periodically as specified by the Airavata ADMIN users.

 

    • Verifying application location in the resource(s) and actual existence

    • Verifying application version in the resource

    • Verify availability of space on scratch location folders.

Status of Applications & Workflows