That would work for me too:-) IIRC, PBS/Torque's qstat has flags to control the details, and I'm using it to get the queue, nodes and jobs.
Bruno ------------------------------ Em sáb, 13 de set de 2014 04:16 BRT Andre Merzky escreveu: >> Maybe it would be useful to >> have a 'slim' method that returns a lightweight structure, and another one >> that returns the complete info? > >If we want to control that (and I am not sure we do), then I would >prefer a flag to the call instead of a separate call. > ></bikeshed> ;) > > Andre. > > >On Sat, Sep 13, 2014 at 1:39 AM, Bruno P. Kinoshita ><[email protected]> wrote: >> I think can't contribute much in this discussion. In my case we store the >> job ID returned by the API, and store the information we supplied + this job >> ID in a local datastore. >> >> The filtering is local, using the data returned periodically from the >> cluster (a thread running in background updating the tool queue). This way >> users will be able to filter for jobs (by name, queue, priority, etc) but >> most of the data is already in the tool. The most important information >> retrieved from the server for us is the job status. >> >> So in my case I think that this issue is not a blocker, but depending on how >> users want to use the API this can be useful. Maybe it would be useful to >> have a 'slim' method that returns a lightweight structure, and another one >> that returns the complete info? >> >> My 0.02 cents too :) >> Bruno >> >> ________________________________ >> From: Andre Merzky <[email protected]> >> To: Peter Tröger <[email protected]> >> Cc: drmaa-wg <[email protected]> >> Sent: Friday, September 12, 2014 5:18 PM >> Subject: Re: [DRMAA-WG] What information should JobInfo provide ? >> >> I think the job template information are easy to add, and make app >> writing easier (I don't need to keep the old submitted job template >> around...). Only drawback I see is increase in memory footprint when >> used to report on many jobs -- but when used as a filtering >> instruction, this should not matter. >> >> >> My $0,02, Andre. >> >> On Wed, Sep 10, 2014 at 7:48 PM, Peter Tröger <[email protected]> wrote: >> Dear all, >> >> at OGF-42, we stumbled over the issue that „JobInfo“ does not contain the >> original job name being used in the template: >> >> http://redmine.ogf.org/issues/102 >> >> This leads to the situation that you cannot filter for it when doing >> monitoring. >> >> Although we quickly decided to add it, I meanwhile figured out that this >> is a deeper problem. JobInfo intentionally contains nothing from the job >> template at the moment, which makes perfectly sense if you see it as a pure >> reporting data structure. You don’t need to fetch information that you >> handed in by yourself as the calling application. >> >> For filtering, however, you obviously want to have all of the template >> attributes being usable. This is not possible at the moment. >> >> Another case is the „change job template after submission“ magic in Grid >> Engine, which could lead to the fact that your job has different attributes >> from what you originally specified. You may also want to see that in the >> JobInfo structure. >> >> All in all, it seems like that „JobInfo“ needs all of attributes from >> „JobTemplate“ too, not only the job name. >> >> What do you think ? >> >> Best regards, >> Peter. >> >> >> >> >> >> -- >> drmaa-wg mailing list >> [email protected] >> https://www.ogf.org/mailman/listinfo/drmaa-wg >> >> >> >> -- >> It was a sad and disappointing day when I discovered that my Universal >> Remote Control did not, in fact, control the Universe. (Not even >> remotely.) >> >> >> >> -- >> drmaa-wg mailing list >> [email protected] >> https://www.ogf.org/mailman/listinfo/drmaa-wg >> >> > > > >-- >It was a sad and disappointing day when I discovered that my Universal >Remote Control did not, in fact, control the Universe. (Not even >remotely.) -- drmaa-wg mailing list [email protected] https://www.ogf.org/mailman/listinfo/drmaa-wg
