Hi, anybody interested in the OCCI/DRMAAv2 stuff and is willing to help - feel free to ping me. I'm still at the very beginning but might have something soon... Cheers, -Thijs -----Ursprüngliche Nachricht----- Von: drmaa-wg-bounces@ogf.org im Auftrag von Peter Tröger Gesendet: Do 15-Jul-10 14:28 An: drmaa-wg@ogf.org Cc: Betreff: [DRMAA-WG] Meeting Minutes of Conference call - Jul 14th - 19:00 UTC 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.