Added some of the assumptions/goals to the intro #44
Conversation
hategan
requested review from
shantenujha,
SteVwonder,
andre-merzky and
mturilli
| in an abstract way; that is, it must use a job management API. The only stable | ||
| job management API currently available is | ||
| [SAGA](http://radical-cybertools.github.io/) [so, wait a minute, how do we | ||
| justify not pushing SAGA forward?]. |
There was a problem hiding this comment.
I think I will need to leave others to clarify this. One argument I heard on the call (but not one I would make, just repeating) is that SAGA, or at least the name, comes with a certain pre-notation / ballast, and that would at least partially justify to distinguish an Exaworks job API from it.
BTW: DRMAA also is an existing, stable API -- just not a widely implemented one (anymore). As such, we should also motivate why we do not implement DRMAA instead of inventing our own API.
| scope, such as [Globus | ||
| GRAM](https://en.wikipedia.org/wiki/Grid_resource_allocation_manager), | ||
| [SAGA](http://radical-cybertools.github.io/), and | ||
| [DRMAA](http://www.drmaa.org/). |
There was a problem hiding this comment.
I would suggest to add DRMAA, but also Flux here. We could also add POSIX FWIW (qsub etc): even though POSIX does not define an LRM API, it does define those command line tools which are widely considered the standard interface in many LRM implementations.
Let's use this PR to discuss the assumptions, motivations, and goals for the API and edit the relevant section appropriately.
One of the topics that came up was that we need to articulate why we are designing a new API rather than using, e.g., SAGA or DRMAA, Flux, or even standard qsub. @andre-merzky is working on this.