[DRMAA-WG] What information should JobInfo provide ?

[Andre Merzky]

> 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.)