airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From IU-Gmail <raminderjsi...@gmail.com>
Subject Re: Enabling Workflow Support through Orchestrator
Date Tue, 24 Jun 2014 15:17:47 GMT
In choice 3 what does "launchExperiment(Experiment experiment)” mean?  This will add confusion
for the API user and developer. I like choice 3 for clarity and we already have workflow related
elements in the experiment Struct. 

Thanks
Raminder
On Jun 24, 2014, at 10:00 AM, Suresh Marru <smarru@apache.org> wrote:

> This is a good summary. I am inclined on Choice 3. The experiment data structure is similar
for both single application and workflows, but the API calls are explicit. From a user stand
point, both application and workflows have inputs, outputs and QoS configurations. But the
level of details exposed in workflows is more granular. So the data structure can be re-used.
> 
> I also worry about using the magic parameters, the more we stay away from XOR like situations,
it may be unambiguous. 
> 
> Suresh
> 
> On Jun 24, 2014, at 9:36 AM, Marlon Pierce <marpierc@iu.edu> wrote:
> 
>> Hi Saminda--
>> 
>> Can you say more about why you have three options and what the tradeoffs are?  Below
is my understanding.
>> 
>> * Choice 2: one launch method and one executableId for both workflows and single
applications, so they are treated in the API as fundamentally the same. Beautiful uniformity
but may be more contorted to implement.  I like this as an API call but implementing it may
have unintended consequences.
>> 
>> * Choice 1: still has a universal launch method and execID but makes the execution
type explicit with ExecType.  This makes the API user responsible for making this choice.
 Increases the chance that the API user will make a mistake.  I don't like it for that reason.
>> 
>> * Choice 3: different methods for launching single apps and workflows, but the Experiment
structure is the same as Choice 2. Not as beautiful as Choice 2 but may have a cleaner implementation.
API user probably knows they need a workflow, but what happens if they send an Experiment
object of the wrong type to one of the methods (workflow Experiment to launchApplication)?
>> 
>> * Choice 4 (not shown): like Choice 3 but with WorkflowExperiment struct for workflows
and launchWorkflow(WorkflowExperiment).
>> 
>> 
>> I like Choice 2 (keep the API simple) and then Choice 4 (if you can't make it simple,
make it unambiguous).  Choice 2 is my least favorite (API user must supply the right magic
parameter).
>> 
>> 
>> Marlon
>> 
>> 
>> 
>> On 6/23/14, 7:56 PM, Saminda Wijeratne wrote:
>>> In order to distinguish single application vs workflow execution in the API
>>> we thought of few choices (trivial parameters not shown here and proposed
>>> parameter/property names not well thought out yet).
>>> 
>>> *Choice 1*
>>> launchExperiment(Experiment experiment)
>>> struct Experiment{
>>>   ...
>>>   string executableId // application id for single app or workflow
>>> template id for workflow
>>>   ExecType type // SINGLE_APP/WORKFLOW
>>>   ...
>>> }
>>> 
>>> *Choice 2*
>>> launchExperiment(Experiment experiment)
>>> struct Experiment{
>>>   ...
>>>   string executableId // unique id for application id for single app or
>>> workflow template id for workflow
>>>   ...
>>> }
>>> 
>>> *Choice 3*
>>> launchApplication(Experiment experiment)
>>> launchWorkflow(Experiment experiment)
>>> 
>>> launchExperiment(Experiment experiment)
>>> struct Experiment{
>>>   ...
>>>   string executableId // application id for single app or workflow
>>> template id for workflow
>>>   ...
>>> }
>>> 
>>> Any thoughts?
>>> 
>>> 
>>> On Mon, Jun 23, 2014 at 7:30 PM, Saminda Wijeratne <samindaw@gmail.com>
>>> wrote:
>>> 
>>>> With a few updates to the Orchestrator CPI we are carrying ahead the
>>>> updating the workflow interpreter to support workflow executions in
>>>> Airavata for 0.13 release as the attached diagram.
>>>> 
>>>> 
>>>> [image: Inline image 1]
> 


Mime
View raw message