Return-Path: X-Original-To: apmail-airavata-dev-archive@www.apache.org Delivered-To: apmail-airavata-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id F368510F4D for ; Fri, 17 Jan 2014 18:20:51 +0000 (UTC) Received: (qmail 23170 invoked by uid 500); 17 Jan 2014 18:20:51 -0000 Delivered-To: apmail-airavata-dev-archive@airavata.apache.org Received: (qmail 23126 invoked by uid 500); 17 Jan 2014 18:20:50 -0000 Mailing-List: contact dev-help@airavata.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@airavata.apache.org Delivered-To: mailing list dev@airavata.apache.org Received: (qmail 23119 invoked by uid 99); 17 Jan 2014 18:20:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Jan 2014 18:20:50 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of thejaka.amila@gmail.com designates 209.85.219.46 as permitted sender) Received: from [209.85.219.46] (HELO mail-oa0-f46.google.com) (209.85.219.46) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Jan 2014 18:20:43 +0000 Received: by mail-oa0-f46.google.com with SMTP id n16so1978728oag.33 for ; Fri, 17 Jan 2014 10:20:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Y+vQtmDN6BTmaKQovgXjDrWtMWE4s4x3g8xEJxjmPfw=; b=HFmNRAWCp6mUM4fMxjwfkeBqKdtROBHHgaxEdw2rCH1mBClfiIerfqet1xPj6iVTEP WcrLEeEYAhSjVCLIujRcI/2xJTyt/CwFSqdgKUBpwxI7WUpOpnJGVqy90AtfDnvDlg4o Czo1Woo4bycVU0EyCQsGguvzRNJ5rJzN8Ao58CoUT57isFkzhtHQW5tWrGy6vBRrLSps pY0gxfoWVklxJ6ctC08ZFn3q3Lsu7LFaMsofxxlahde5eIvWsLiMfEaXKAI6xSVPKtQX w/k1IxnPgbG89Cr85yx6EtSa08yqT9IsF1lOOX2+UsiaCuW7tUIdo78rSSaYfIaJOggc zang== MIME-Version: 1.0 X-Received: by 10.182.220.225 with SMTP id pz1mr2657346obc.51.1389982822448; Fri, 17 Jan 2014 10:20:22 -0800 (PST) Received: by 10.76.169.230 with HTTP; Fri, 17 Jan 2014 10:20:22 -0800 (PST) In-Reply-To: References: Date: Fri, 17 Jan 2014 13:20:22 -0500 Message-ID: Subject: Re: Orchestrator Overview Meeting Summary From: Amila Jayasekara To: dev Content-Type: multipart/alternative; boundary=001a11c30fac6043c504f02e986f X-Virus-Checked: Checked by ClamAV on apache.org --001a11c30fac6043c504f02e986f Content-Type: text/plain; charset=ISO-8859-1 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 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 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 < >> thejaka.amila@gmail.com> wrote: >> >>> >>> >>> >>> On Thu, Jan 16, 2014 at 10:58 AM, Sachith Withana 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 >> >> > --001a11c30fac6043c504f02e986f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This seems like adding new experiment definition. (i.e. ne= w descriptors).
As far as I understood this should be handled at UI lay= er (?). 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 <samindaw@gmail.com>= wrote:
This was in accordance with= the CIPRES usecase scenario where users would want to rerun their tasks bu= t 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 W= ithana <swsachith@gmail.com> wrote:
Hi Amila,

The use of the word "cloning" is misleading.

Saminda suggested that, we would need to run the application in a diff= erent host ( based on the users intuition of the host availability/ efficie= ncy) keeping all the other variables constant( inputs changes are also allo= wed). As an example: if a job keeps failing on one host, the user should be= allowed to submit the job to another host.=A0

We should come up with a different name for the scenari= o..=A0


On Thu, Jan 16, 2014 at 11:36 PM, Amila Jayasekara <thejaka.amila@gmail.com> wrote:



On Thu, Jan 16, 2014 at 10:58 A= M, Sachith Withana <swsachith@gmail.com> wrote:
Hi All,

This is the summary of the meeting we had Wednesday( 01/16/14) on t= he Orchestrator.

Orchestrator Overview
I Introduced the Orches= trator 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 j= ob and run it with different inputs or on a different host or both. Here= 9;s the Jira for that.[1]

I didnt quite understand= what cloning does. Once descriptors are setup we can run experiment with d= ifferent inputs, many times we want. So what is the actual need to have clo= ning ?

Thanks
Thejaka Amila
=A0
=

Gfac embedded vs Gfac as a service
We have implement= ed the embedded Gfac and decided to use it for now.=A0
Gfac as a = service is a long term goal to have. Until we get the Orchestrator complete= we will use the embedded Gfac.=A0

Job statuses for the Orchestrator and the Gfac
We ne= ed 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 dis= cussion. We didn't come to a conclusion on the matter. We will discuss = this topic in an upcoming meeting.=A0



--
Thanks,
Sachith Withana





<= font color=3D"#888888">--
Thanks,
Sachith Withana



--001a11c30fac6043c504f02e986f--