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