[DRMAA-WG] Meeting Minutes of Conference call - Jul 14th - 19:00 UTC
Thijs Metsch
tmetsch at platform.com
Thu Jul 15 08:45:14 CDT 2010
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 at ogf.org im Auftrag von Peter Tröger
Gesendet: Do 15-Jul-10 14:28
An: drmaa-wg at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/drmaa-wg/attachments/20100715/b41afdf4/attachment.html
More information about the drmaa-wg
mailing list