On Tue, Apr 15, 2014 at 2:51 PM, Amila Jayasekara <[email protected]>wrote:
> On Tue, Apr 15, 2014 at 2:38 PM, Lahiru Gunathilake <[email protected] > >wrote: > > > 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. > > > > Is that so ? > i.e. user specifies the resource when launching the application ? not when > creating the experiment ? > When user create experiment it gives the host name and during launching the actual binding happens by loading the appropriate application descriptor. > > Thanks > Amila > > > > > > 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 > > > -- System Analyst Programmer PTI Lab Indiana University
