Peter
- 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 ?
Not covered due to time restrictions.
The next phone conference is in two weeks.
Best,
Peter.