> 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
