airavata-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raminderjeet Singh (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AIRAVATA-1551) Handling Application Outputs
Date Tue, 13 Jan 2015 20:24:34 GMT

     [ https://issues.apache.org/jira/browse/AIRAVATA-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Raminderjeet Singh updated AIRAVATA-1551:
-----------------------------------------
    Description: 
Scientific applications consume inputs and produce outputs. Currently, we handle application
outputs either by scanning STDOUT or looking into output data directory. We had to add wrapper
scripts for different application to handle outputs in the way Airavata understands. Output
handler code is overloaded with those details and difficult to extend/improve. To improve
output handler code and to support application without wrapper scripts, we need to rewrite
these handlers. 

Requirements for new code are:
1. New handler code should work based on experiment object or a internal gfac context. 
2. Stop scanning STDOUT file for outputs and use gateway defined output names/locations to
map outputs.
3. STDOUT and STDERR will be output for every application and we will not treat them as special
outputs.
4. Primitive type data types(STRING, INT) will not be supported for batch job. They always
produce stdout and stderr and these will be output for simple jobs like ECHO. So output for
echo like jobs can be found in stdout file.

  was:
Scientific applications consume inputs and produce outputs. Currently, we handle application
outputs either by scanning STDOUT or looking into output data directory. We had to add wrapper
scripts for different application to  handle outputs in the way Airavata understand outputs.
Output handler code is  overloaded with these details and difficult to extend. To improve
output handler code and to support application without wrapper scripts, we need to rewrite
these handlers. 
Requirements for new code are:
1. New handler code should work based on experiment object or a internal gfac context. 
2. Stop scanning STDOUT file for outputs and use gateway defined output names to identified
outputs.
3. STDOUT and STDERR will be output for every application and we will not treat them as special
outputs.
4. Primitive type data types will not be supported for Batch job. They always produce stdout
and stderr and these will be output for simple jobs like ECHO. 


> Handling Application Outputs
> ----------------------------
>
>                 Key: AIRAVATA-1551
>                 URL: https://issues.apache.org/jira/browse/AIRAVATA-1551
>             Project: Airavata
>          Issue Type: Story
>          Components: Airavata API, Application Catalog, GFac
>    Affects Versions: 0.15 
>            Reporter: Raminderjeet Singh
>            Assignee: Raminderjeet Singh
>
> Scientific applications consume inputs and produce outputs. Currently, we handle application
outputs either by scanning STDOUT or looking into output data directory. We had to add wrapper
scripts for different application to handle outputs in the way Airavata understands. Output
handler code is overloaded with those details and difficult to extend/improve. To improve
output handler code and to support application without wrapper scripts, we need to rewrite
these handlers. 
> Requirements for new code are:
> 1. New handler code should work based on experiment object or a internal gfac context.

> 2. Stop scanning STDOUT file for outputs and use gateway defined output names/locations
to map outputs.
> 3. STDOUT and STDERR will be output for every application and we will not treat them
as special outputs.
> 4. Primitive type data types(STRING, INT) will not be supported for batch job. They always
produce stdout and stderr and these will be output for simple jobs like ECHO. So output for
echo like jobs can be found in stdout file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message