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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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] >
