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
