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 <brunodepaulak@yahoo.com.br> 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 <andre@merzky.net> To: Peter Tröger <peter@troeger.eu> Cc: drmaa-wg <drmaa-wg@ogf.org> 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 <peter@troeger.eu> 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 drmaa-wg@ogf.org 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 drmaa-wg@ogf.org 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.)