airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saminda Wijeratne <samin...@gmail.com>
Subject Re: Orchestrator Overview Meeting Summary
Date Fri, 17 Jan 2014 19:05:11 GMT
an experiment will not define new descriptors but rather point to an
existing descriptor(s). IMO (correct me if I'm wrong),

Experiment = Application + Input value(s) for application + Configuration
data for managing job

Application = Service Descriptor + Host Descriptor + Application Descriptor

Thus for an experiment it involves quite the amount of data of which needs
to be specified. Thus it is easier to make a copy of it rather than asking
the user to specify all of the data again when only there are very few
changes compared to original experiment. Perhaps the confusion here is the
word "clone"?


On Fri, Jan 17, 2014 at 10:20 AM, Amila Jayasekara
<thejaka.amila@gmail.com>wrote:

> 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 <samindaw@gmail.com>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 <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
>>> 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 <swsachith@gmail.com>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
>>>
>>>
>>
>

Mime
View raw message