airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saminda Wijeratne <>
Subject Re: Application Catalog Design Phase-I
Date Sun, 11 May 2014 19:25:08 GMT
Thank you all for your feedback from both the mailing list and google
hangout discussions. As for the last weeks google hangout discussion we
came to the following conclusions regarding phase 1.

   - Focus only on thrift data model ComputeResourceDescription[1] (i.e.
      - we'll re-evaluate the design after the tutorial
   - Thrift API functions will be defined for the thrift data model
   ComputeResourceDescription and its supporting models in a separate thrift
   - Thrift data models for the rest of the Application Catalog components
   will be focussed upon later
   - Reuse the existing ServiceDescriptor and ApplicationDescriptor schema
      objects for the time-being to fill the missing void in the application
   - A new component called "Application Catalog" will be introduced along
   with a CPI for it
   - We will be saving ComputeResourceDescription as the way we save thrift
   objects. But ApplicationDescriptor and ServiceDescriptor will be saved as
   blobs with basic id/name metadata fields to allow querying.
   - Samples and tests which used descriptors to add applications will use
   the new CPI/API functions as necessary to add applications to the
   Application Catalog
   - GFac will retrieve applications from the application catalog retiring
   the old Airavata API completely. However in order to minimize the changes
   at GFac side it will transform the application catalog to schema objects
   service/host/application descriptors.
   - We will attempt to complete these changes by 16th May in order to
   start testing and using them by next week.



On Tue, May 6, 2014 at 12:11 PM, Raminder Singh <>wrote:

> Thanks Sachith.  We can have host object independent of application as the
> same host definition can be used for multiple applications. Please add
> complete details of host and application properties like Application
> type(MPI, OpenMP, MapReduce etc), JobManager (PBS, SLURM,EC2). You need to
> consider extensibility of the models also as requirements may change with
> job or monitoring manager details.
> Thanks
> Raminder
> On May 5, 2014, at 4:12 PM, Sachith Withana <> wrote:
> Hi all, After an offline discussion, we came up with an initial
> Application Catalog design which captures the minimum requirements.
> Any suggestions?
> Functionalities for the Gateway API Thrift Functions
>    - add // (not required for tutorial but will make life easier for us)
>    - String add(application)  //return application id
>    -
>       - String add(applicationId,deployment) //return deployment id
>       - get
>    - get(applicationId)  //return application
>       - get(applicationId, deploymentId) //return deployment
>       - remove //optional
>    - remove(applicationId)
>       - remove(applicationId, deploymentId)
>       - update //optional
>    - update(application)
>       - update(applicationId, deployment)
>       - list
>    - String[] list()  // list of application ids
>       - String[] list(applicationId) // list of deployment ids
> API Thrift Data model
> Application (application id)
>  Input* : name/type/optional?
>  Output* : name/type/optional?/
>  Deployment* (deployment id)
>  Host (host id)
>  host IP
>  host job management protocol and properties
>  host data management protocol and properties
>  executable path
>  scratch location
>  job properties (key/value default values)
>   eg: Project Id, CPU count, Node count, Wall time
>   *0 or more
> BOLD : minimum requirement
> --
> Thanks,
> Sachith Withana

View raw message