Minutes from Conference call - Jun 23th
In Attendance: Dan Templeton Roger Brobst Mariusz Daniel Gruber
1. Meeting secretary ? Roger
2. Monitoring jobs not submitted by DRMAA - final decision
- Important to be able to obtain information about non-DRMAA jobs which have not ended. - Desirable to obtain information about non-DRMAA jobs which have recently ended, where "recently" is DRM-defined. - Importance (and ability to obtain) information about jobs submitted by others unclear. Agreed that if there is support for obtaining information about other's jobs, must support a filter to limit to current user's jobs. - Desirable to obtain information about non-DRMAA jobs using APIs similar to those used for jobInfo. Use Dictionary type to support DRM-specific info.
5. Cleaning up the spreadsheet:
No discussion.
Hi,
2. Monitoring jobs not submitted by DRMAA - final decision
- Important to be able to obtain information about non-DRMAA jobs which have not ended.
- Desirable to obtain information about non-DRMAA jobs which have recently ended, where "recently" is DRM-defined.
- Importance (and ability to obtain) information about jobs submitted by others unclear. Agreed that if there is support for obtaining information about other's jobs, must support a filter to limit to current user's jobs.
- Desirable to obtain information about non-DRMAA jobs using APIs similar to those used for jobInfo. Use Dictionary type to support DRM-specific info.
After some thinking, I decided to put that into the JobSession interface: === snip === interface JobSession { readonly attribute string contact; readonly attribute string sessionName; Job getJob(string jobId); sequence<Job> getSessionJobs(JobInfo filter); sequence<Job> getAllJobs(JobInfo filter); Job runJob(in DRMAA::JobTemplate jobTemplate) raises (???); ... === snip === Non-session jobs are identified by not having the Job::session attribute set. I am still unsure about the "filtering for current user" part, since this would bring us the concept of user name, which was omitted so far. Best, Peter.
5. Cleaning up the spreadsheet:
No discussion. -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
Not sure I like that in the JobSession. I mean, it *is* the *Job*Session, but that would mean writing a monitoring tool would require keeping two sessions open. As for the filtering, it should be possible to filter on any job attribute. We have not yet discussed job owner as a job attribute, but now that we've opened the possibility of monitoring other users' jobs, I think we have to consider it. I don't see an issue with it. If it's a security problem, then the DRM is free to hide anything that shouldn't be exposed. And I still don't see any resolution for the problem of getting back a list of several hundred thousand jobs. I think we've had this discussion before. Anyone have notes on what we decided? Daniel On 07/06/10 15:16, Peter Tröger wrote:
Hi,
2. Monitoring jobs not submitted by DRMAA - final decision
- Important to be able to obtain information about non-DRMAA jobs which have not ended.
- Desirable to obtain information about non-DRMAA jobs which have recently ended, where "recently" is DRM-defined.
- Importance (and ability to obtain) information about jobs submitted by others unclear. Agreed that if there is support for obtaining information about other's jobs, must support a filter to limit to current user's jobs.
- Desirable to obtain information about non-DRMAA jobs using APIs similar to those used for jobInfo. Use Dictionary type to support DRM-specific info.
After some thinking, I decided to put that into the JobSession interface:
=== snip === interface JobSession { readonly attribute string contact; readonly attribute string sessionName; Job getJob(string jobId); sequence<Job> getSessionJobs(JobInfo filter); sequence<Job> getAllJobs(JobInfo filter); Job runJob(in DRMAA::JobTemplate jobTemplate) raises (???); ... === snip === Non-session jobs are identified by not having the Job::session attribute set. I am still unsure about the "filtering for current user" part, since this would bring us the concept of user name, which was omitted so far.
Best, Peter.
5. Cleaning up the spreadsheet:
No discussion. -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
Am 07.07.2010 um 20:52 schrieb Daniel Templeton:
Not sure I like that in the JobSession. I mean, it *is* the *Job*Session, but that would mean writing a monitoring tool would require keeping two sessions open.
Completely agreed. The method is now in MonitoringSession.
As for the filtering, it should be possible to filter on any job attribute. We have not yet discussed job owner as a job attribute, but now that we've opened the possibility of monitoring other users' jobs, I think we have to consider it. I don't see an issue with it. If it's a security problem, then the DRM is free to hide anything that shouldn't be exposed.
Good that we already solved that ;-) We decided earlier to perform filtering on the job list from JobSession with the JobInfo structure. Since the structure already contains the job owner information, the problem is solved.
And I still don't see any resolution for the problem of getting back a list of several hundred thousand jobs. I think we've had this discussion before. Anyone have notes on what we decided?
We also discussed that, and basically agreed on trusting in the OO language's scalability capabilities. Best, Peter.
Daniel
On 07/06/10 15:16, Peter Tröger wrote:
Hi,
2. Monitoring jobs not submitted by DRMAA - final decision
- Important to be able to obtain information about non-DRMAA jobs which have not ended.
- Desirable to obtain information about non-DRMAA jobs which have recently ended, where "recently" is DRM-defined.
- Importance (and ability to obtain) information about jobs submitted by others unclear. Agreed that if there is support for obtaining information about other's jobs, must support a filter to limit to current user's jobs.
- Desirable to obtain information about non-DRMAA jobs using APIs similar to those used for jobInfo. Use Dictionary type to support DRM-specific info.
After some thinking, I decided to put that into the JobSession interface:
=== snip === interface JobSession { readonly attribute string contact; readonly attribute string sessionName; Job getJob(string jobId); sequence<Job> getSessionJobs(JobInfo filter); sequence<Job> getAllJobs(JobInfo filter); Job runJob(in DRMAA::JobTemplate jobTemplate) raises (???); ... === snip === Non-session jobs are identified by not having the Job::session attribute set. I am still unsure about the "filtering for current user" part, since this would bring us the concept of user name, which was omitted so far.
Best, Peter.
5. Cleaning up the spreadsheet:
No discussion. -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
On 7/12/10 1:04 PM, Peter Tröger wrote:
Am 07.07.2010 um 20:52 schrieb Daniel Templeton:
And I still don't see any resolution for the problem of getting back a list of several hundred thousand jobs. I think we've had this discussion before. Anyone have notes on what we decided?
We also discussed that, and basically agreed on trusting in the OO language's scalability capabilities.
That's what I was afraid of. Let me go stew about that a little, and I'll be ready to argue about it on the next call. ;) Daniel
Best, Peter.
Daniel
On 07/06/10 15:16, Peter Tröger wrote:
Hi,
2. Monitoring jobs not submitted by DRMAA - final decision
- Important to be able to obtain information about non-DRMAA jobs which have not ended.
- Desirable to obtain information about non-DRMAA jobs which have recently ended, where "recently" is DRM-defined.
- Importance (and ability to obtain) information about jobs submitted by others unclear. Agreed that if there is support for obtaining information about other's jobs, must support a filter to limit to current user's jobs.
- Desirable to obtain information about non-DRMAA jobs using APIs similar to those used for jobInfo. Use Dictionary type to support DRM-specific info.
After some thinking, I decided to put that into the JobSession interface:
=== snip === interface JobSession { readonly attribute string contact; readonly attribute string sessionName; Job getJob(string jobId); sequence<Job> getSessionJobs(JobInfo filter); sequence<Job> getAllJobs(JobInfo filter); Job runJob(in DRMAA::JobTemplate jobTemplate) raises (???); ... === snip === Non-session jobs are identified by not having the Job::session attribute set. I am still unsure about the "filtering for current user" part, since this would bring us the concept of user name, which was omitted so far.
Best, Peter.
5. Cleaning up the spreadsheet:
No discussion. -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
On 07/12/10 22:04, Peter Tröger wrote:
Am 07.07.2010 um 20:52 schrieb Daniel Templeton:
Not sure I like that in the JobSession. I mean, it *is* the *Job*Session, but that would mean writing a monitoring tool would require keeping two sessions open.
Completely agreed. The method is now in MonitoringSession.
Is there any need to have more than one MonitoringSession per application? If not we have to make it a singleton. Daniel
As for the filtering, it should be possible to filter on any job attribute. We have not yet discussed job owner as a job attribute, but now that we've opened the possibility of monitoring other users' jobs, I think we have to consider it. I don't see an issue with it. If it's a security problem, then the DRM is free to hide anything that shouldn't be exposed.
Good that we already solved that ;-) We decided earlier to perform filtering on the job list from JobSession with the JobInfo structure. Since the structure already contains the job owner information, the problem is solved.
And I still don't see any resolution for the problem of getting back a list of several hundred thousand jobs. I think we've had this discussion before. Anyone have notes on what we decided?
We also discussed that, and basically agreed on trusting in the OO language's scalability capabilities.
Best, Peter.
Daniel
On 07/06/10 15:16, Peter Tröger wrote:
Hi,
2. Monitoring jobs not submitted by DRMAA - final decision
- Important to be able to obtain information about non-DRMAA jobs which have not ended.
- Desirable to obtain information about non-DRMAA jobs which have recently ended, where "recently" is DRM-defined.
- Importance (and ability to obtain) information about jobs submitted by others unclear. Agreed that if there is support for obtaining information about other's jobs, must support a filter to limit to current user's jobs.
- Desirable to obtain information about non-DRMAA jobs using APIs similar to those used for jobInfo. Use Dictionary type to support DRM-specific info.
After some thinking, I decided to put that into the JobSession interface:
=== snip === interface JobSession { readonly attribute string contact; readonly attribute string sessionName; Job getJob(string jobId); sequence<Job> getSessionJobs(JobInfo filter); sequence<Job> getAllJobs(JobInfo filter); Job runJob(in DRMAA::JobTemplate jobTemplate) raises (???); ... === snip === Non-session jobs are identified by not having the Job::session attribute set. I am still unsure about the "filtering for current user" part, since this would bring us the concept of user name, which was omitted so far.
Best, Peter.
5. Cleaning up the spreadsheet:
No discussion. -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
Even though this would not be expressible in IDL, it is a relevant detail for the language binding. I put it on the agenda for tomorrow. Best, Peter. Am 13.07.2010 um 16:39 schrieb Daniel Gruber:
On 07/12/10 22:04, Peter Tröger wrote:
Am 07.07.2010 um 20:52 schrieb Daniel Templeton:
Not sure I like that in the JobSession. I mean, it *is* the *Job*Session, but that would mean writing a monitoring tool would require keeping two sessions open.
Completely agreed. The method is now in MonitoringSession.
Is there any need to have more than one MonitoringSession per application? If not we have to make it a singleton.
Daniel
As for the filtering, it should be possible to filter on any job attribute. We have not yet discussed job owner as a job attribute, but now that we've opened the possibility of monitoring other users' jobs, I think we have to consider it. I don't see an issue with it. If it's a security problem, then the DRM is free to hide anything that shouldn't be exposed.
Good that we already solved that ;-) We decided earlier to perform filtering on the job list from JobSession with the JobInfo structure. Since the structure already contains the job owner information, the problem is solved.
And I still don't see any resolution for the problem of getting back a list of several hundred thousand jobs. I think we've had this discussion before. Anyone have notes on what we decided?
We also discussed that, and basically agreed on trusting in the OO language's scalability capabilities.
Best, Peter.
Daniel
On 07/06/10 15:16, Peter Tröger wrote:
Hi,
2. Monitoring jobs not submitted by DRMAA - final decision
- Important to be able to obtain information about non-DRMAA jobs which have not ended.
- Desirable to obtain information about non-DRMAA jobs which have recently ended, where "recently" is DRM-defined.
- Importance (and ability to obtain) information about jobs submitted by others unclear. Agreed that if there is support for obtaining information about other's jobs, must support a filter to limit to current user's jobs.
- Desirable to obtain information about non-DRMAA jobs using APIs similar to those used for jobInfo. Use Dictionary type to support DRM-specific info.
After some thinking, I decided to put that into the JobSession interface:
=== snip === interface JobSession { readonly attribute string contact; readonly attribute string sessionName; Job getJob(string jobId); sequence<Job> getSessionJobs(JobInfo filter); sequence<Job> getAllJobs(JobInfo filter); Job runJob(in DRMAA::JobTemplate jobTemplate) raises (???); ... === snip === Non-session jobs are identified by not having the Job::session attribute set. I am still unsure about the "filtering for current user" part, since this would bring us the concept of user name, which was omitted so far.
Best, Peter.
5. Cleaning up the spreadsheet:
No discussion. -- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
-- drmaa-wg mailing list drmaa-wg@ogf.org http://www.ogf.org/mailman/listinfo/drmaa-wg
participants (4)
-
Daniel Gruber -
Daniel Templeton -
Peter Tröger -
Roger Brobst