[DRMAA-WG] What information should JobInfo provide ?

[Bruno P. Kinoshita]

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 at 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 at merzky.net>
>> To: Peter Tröger <peter at troeger.eu>
>> Cc: drmaa-wg <drmaa-wg at 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 at 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 at 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 at 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.)