On Tue, Apr 15, 2014 at 2:29 PM, Marlon Pierce <[email protected]> wrote:
> 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. > During launching in orchestrator. Currently these are read from application description and its resource specific. Each resource has its own application descriptor. Lahiru > > 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 > >> > > -- System Analyst Programmer PTI Lab Indiana University
