[DRMAA-WG] Meeting Minutes of Conference call - Jul 14th - 19:00 UTC

[Peter Tröger]

Participants: Dan, Daniel, Mariusz, Roger, Peter

> 1. Meeting secretary ?

Peter

> 2. News from the OCCI folks (check http://tinyurl.com/34g583r )

- OCCI group develops job submission and control interface, based on HTTP / REST concept
- Contact with Thijs Metsch, idea of adopting DRMAAv2 semantics for their interface layout (job template, job control functions)
- Early reference implementation can be expected, good first sanity check for some DRMAAv2 concepts

> 3. Is JobInfo as filter in MonitoringSession::getAllJobs good enough ?

- One use case would be to ask for all jobs that didn't succeed -> possible
- Agreement that complex filtering language is overkill, user should do rough filtering through the API, and might perform fine-grained filtering manually afterwards
- Proposal: Maybe a reduced version of JobInfo fits better as filter expression
	- Would demand that somebody decides upon the set of reasonable filter attributes
	- Current approach instead allows "to filter on what you can monitor"
	- Reduced structure would allow to have a cleaner definition of semantics
	- Voting decision: Stick with JobInfo based approach (3:2 votes)
	- JobInfo documentation must therefore mention both cases 

> 4. Scalability issues with getting thousands of job objects as result value (Dan)

- Asking for all jobs in production SGE might lead to 300k job objects being created
- Some discussion about iterator as alternative result type
	- Iterator support in programming languages does not allow to get number of results - how to do pagination ?
	- Iterators look ugly in C, we had it in DRMAA1
	- Silver bullet counter argument (this time not by Dan): Getting all jobs makes only sense with snapshot semantics, so iterator is the wrong approach
- Conclusion: Scalability problem cannot be covered on API level -> good luck for the implementors

> 5. subState inconsistency (Daniel G.)

- change subState type to "native" on all occasions

> 6. JobTemplate::drmsAttributes is still unclear (Daniel G.)

- nativeSpecification allowed to use the same DRMAA library implementation for a new underlying DRMS version
	- Use brand-new feature through its string name in nativeSpecification
- This is no longer possible withJobTemplate::drmsAttribute
	- DRMAA implementation defines the set of valid keys
	- Discussion result: This is intentional, and it's good for job template sanity checks
- Library could accept arbitrary key names, or "nativeSpec" key name
	- Discussion about adding an according non-recommended recommendation to the spec
	- Majority voted for just leaving this out, implementors a creative enough on their own

> 7. MonitoringSession as singleton (Daniel G.)

- Not valid, since MonitoringSession instances are created through SessionManager

> 8. Since job templates are now structs, should we do the same with ReservationTemplate ?
> 9. What shall we do with ReservationTemplate::nativeOptions ?
> 10. Add OS version to ReservationTemplate
> 11. What shall we do with email / blockEmail in JobTemplate ?
> 12. First spec page finalized (check http://tinyurl.com/25cy9u7 )

Not covered due to time restrictions.

The next phone conference is in two weeks.

Best,
Peter.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/drmaa-wg/attachments/20100715/b57e0d2f/attachment.html