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 <[email protected]>wrote: > Hi Eroma, > > Please find my answers below. > > > On Mon, Apr 14, 2014 at 10:04 AM, Eroma Abeysinghe < > [email protected]> 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 >
