airavata-architecture mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <marpi...@iu.edu>
Subject Re: Questions & Clarifications on Airavata
Date Tue, 15 Apr 2014 18:29:26 GMT
When is a resource bound to an experiment?  In at least some cases,
max_walltime, cpu count, etc can be resource specific for a given
application.

Marlon

On 4/15/14 2:18 PM, Amila Jayasekara wrote:
> Hi Lahiru,
>
> Some thoughts below;
>
> Regarding 1
>
> Parameters such as max_wall time, cpu count, queue name etc ... should be
> validate at the experiment creating stage.
> Reason : We create experiment in one call and we launch the experiment in a
> different call. So if user specifies an invalid or out of range value for
> walltime or cpucount, he/she will get an error at experiment launch time,
> not during creation time. Thats going to be tedious to user. Therefore we
> need to validate those job specific parameters during experiment creation.
> How to implement : Use gsissh to login to resource and execute a command
> similar to "qstat -q <queue name>" and parse the output. It gives most of
> above parameters. Also there are other commands you could use to get such
> information (But commands will depend on the job scheduler you are using).
>
> Regarding 3
>
> It doesnt sound correct to copy what ever the status when cloning the
> experiment. This could break some of the logic based on experiment status
> and may give wrong information to user.
>
> Thanks
> Amila
>
>
> On Tue, Apr 15, 2014 at 1:47 PM, Lahiru Gunathilake <glahiru@gmail.com>wrote:
>
>> Hi Eroma,
>>
>> Please find my answers below.
>>
>>
>> On Mon, Apr 14, 2014 at 10:04 AM, Eroma Abeysinghe <
>> eroma.abeysinghe@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> I was preparing test cases for Airavata API and few
>>> questions/clarifications;
>>> 1. Do we have a max walltime and CPU count?
>>>
>> Not sure what did you mean by do we have. Yes we have those two properties
>> and its used in most of the unit tests and createLaunchExperiment sample.
>> You can have a look at the code. Currently its mostly a static
>> configuration where gateway administrator set when he/she save the
>> application context but these properties can be configured for each request
>> (job) rather using the static configuration.
>>
>>> 2. We don't define ppn for resource node at creation of experiments. Is
>> it
>>> set internally for each experiment?
>>>
>> Yes but we set this in application Descriptor currently and its been read
>> in gfac, but we can set in Experiment. To clarify this I have answered your
>> last question and please refer that.
>>
>>> 3. When we clone an experiment what is the status that the new cloned
>>> experiment get saved? Is it CREATED ?
>>>
>> We don't save specific state, we simply clone the experiment with a new
>> experiment ID, whatever the status get copied.
>>
>>> 4. Do we have  a defined mapping between experiment status and task
>> status?
>> Currently they are independent statuses. if you can have a look
>> experimentModel.thrift you can see that. but I think we can have some
>> constraint and keep a mapping to avoid conflicting states between
>> experiments, tasks and Jobs. Currently we don't have any rules defined
>> between these statuses.
>>
>>>
>>> --
>>> Thank You,
>>> Best Regards,
>>> Eroma
>>>
>>
>>
>> --
>> System Analyst Programmer
>> PTI Lab
>> Indiana University
>>


Mime
View raw message