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 <[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 >>
