This seems like adding new experiment definition. (i.e. new descriptors). As far as I understood this should be handled at UI layer (?). For the backend it will just be new descriptor definitions (?). Maybe I am missing something.
- AJ On Fri, Jan 17, 2014 at 1:15 PM, Saminda Wijeratne <[email protected]>wrote: > This was in accordance with the CIPRES usecase scenario where users would > want to rerun their tasks but with subset of slightly different > parameters/input. This is particularly useful for them because their tasks > can include more than 20-30 parameters most of the time. > > > On Fri, Jan 17, 2014 at 6:49 AM, Sachith Withana <[email protected]>wrote: > >> Hi Amila, >> >> The use of the word "cloning" is misleading. >> >> Saminda suggested that, we would need to run the application in a >> different host ( based on the users intuition of the host availability/ >> efficiency) keeping all the other variables constant( inputs changes are >> also allowed). As an example: if a job keeps failing on one host, the user >> should be allowed to submit the job to another host. >> >> We should come up with a different name for the scenario.. >> >> >> On Thu, Jan 16, 2014 at 11:36 PM, Amila Jayasekara < >> [email protected]> wrote: >> >>> >>> >>> >>> On Thu, Jan 16, 2014 at 10:58 AM, Sachith Withana >>> <[email protected]>wrote: >>> >>>> Hi All, >>>> >>>> This is the summary of the meeting we had Wednesday( 01/16/14) on the >>>> Orchestrator. >>>> >>>> Orchestrator Overview >>>> I Introduced the Orchestrator and I have attached the presentation >>>> herewith. >>>> >>>> Adding Job Cloning capability to the Orchestrator API >>>> Saminda suggested that we should have a way to clone an existing job >>>> and run it with different inputs or on a different host or both. Here's the >>>> Jira for that.[1] >>>> >>> >>> I didnt quite understand what cloning does. Once descriptors are setup >>> we can run experiment with different inputs, many times we want. So what is >>> the actual need to have cloning ? >>> >>> Thanks >>> Thejaka Amila >>> >>> >>>> >>>> Gfac embedded vs Gfac as a service >>>> We have implemented the embedded Gfac and decided to use it for now. >>>> Gfac as a service is a long term goal to have. Until we get the >>>> Orchestrator complete we will use the embedded Gfac. >>>> >>>> Job statuses for the Orchestrator and the Gfac >>>> We need to come up with multi-level job statuses. User-level, >>>> Orchestartor-level and the Gfac-level statuses. Also the mapping between >>>> them is open for discussion. We didn't come to a conclusion on the matter. >>>> We will discuss this topic in an upcoming meeting. >>>> >>>> >>>> [1] https://issues.apache.org/jira/browse/AIRAVATA-989 >>>> >>>> -- >>>> Thanks, >>>> Sachith Withana >>>> >>>> >>> >> >> >> -- >> Thanks, >> Sachith Withana >> >> >
