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 > >
