You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airavata.apache.org by "Suresh Marru (JIRA)" <ji...@apache.org> on 2013/12/10 05:46:07 UTC

[jira] [Commented] (AIRAVATA-964) Add single job support as a first class simple Apache Airavata Execution

    [ https://issues.apache.org/jira/browse/AIRAVATA-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13843937#comment-13843937 ] 

Suresh Marru commented on AIRAVATA-964:
---------------------------------------

Lahiru started a discussion of this topic on the dev list - http://markmail.org/thread/yprzdxa2znyfrsl3 Since the discussion covered a big topic, it was going long leading to offline documents. How about we break it down and discuss one step after another. I will take a stab with first initial steps. Referring to the attached diagram. First lets extend the current Airavata API to include a simplified execution manager. The new orchestrater component will implement the simple execution API and take incoming requests in persist the request as is in Airavata Registry with a handle (in form of experiment id) returned to the client. This is indicated in Step A in the attached figure. Next the orchestrator will marshall the request, validate user input, verify the required computational security credentials are accessible, bind (schedule) the required computational resource and record the translated GFac consumable request in the registry. The orchestrator then finds a GFac instance to execute the request and invokes it with the experiment Id as indicated in Step B. The Gfac instance then queries registry with the experiment id, fetches all required information and keep updating the registry at well defined check points.

I will stop it here and how about we discuss if the above steps are captured and from the mailing lists discussion and any debates on any steps? 


> Add single job support as a first class simple Apache Airavata Execution
> ------------------------------------------------------------------------
>
>                 Key: AIRAVATA-964
>                 URL: https://issues.apache.org/jira/browse/AIRAVATA-964
>             Project: Airavata
>          Issue Type: Epic
>          Components: Airavata Client, GFac
>            Reporter: Suresh Marru
>              Labels: Architecture
>         Attachments: Airavata-Single-Job-Execution.png
>
>
> Currently Airavata supports single jobs by wrapping it as a single node task within a workflow. This wrapping is justified if workflow is the predominant use of Airavata and single application execution is a rare usage pattern. As Airavata is getting more usage, the simple execution but for large number of invocations and diverse applications is getting more widely used. 
> Providing a first class way of a simple application execution will reduce the overhead in creating and managing workflows. But this takes away all the orchestration capabilities provided by the Workflow Interpreter. This Epic is to discuss a new component to Airavata which provides based job orchestration while persisting the request state to registry so the application management component (GFac) can be stateless and recover the job from a frequently checkpointed state from the registry



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)