API

Purpose of this document

Define main characteristics of the Grid5000 API

Definitions

Grid5000 (G5K)

an infrastructure distributed in 9 sites around France, for research in large-scale parallel and distributed systems.

Site

a location, geographically remarkable, hosting one or more resources at the disposal of G5K principals.

Experiment

a scientific project that tries to solve non-trivial issues, with regard to parallel and distributed systems, by using the Grid5000 platform as a testbed. A principal conducts an experiment by executing a set of jobs (with possible dependencies between them ?) on a set of resources hosted on one or more sites, which have been allocated for its sole usage for a certain period of time.

Job

a discrete unit of work that uses one or more resources of a certain site to execute a specified program during a certain period of time.

Resource

general denomination of a component of G5K: computing or networking asset.

Principal

a physical person or a computing program having been granted an access to G5K.

Program

an original piece of code containing all the instructions required for its correct execution, on a few or any kind of resources.

Functional Requirements

• Experiment management (job submission, experiment supervision and control) should be supported by the API.
• Resource management (description, allocation, manipulation, supervision) should be supported by the API.
• Deployment management (description of environment images, bulk deployment on resources) should be supported by the API.
• Data management (reporting) should be supported by the API.
• Site management should be supported by the API.
• User management should be supported by the API.
• Authentication and authorization should be supported by the API.
• Asynchronous notification (email) should be supported by the API.

• User-Data synchronization should be supported by the API ?

Non-functional Requirements

• Asynchronous operations should be supported by the API.
• Bulk operations should be supported by the API.
• Auditing, logging and accounting should not be exposed.
• QoS does not require explicit support on API level.
• Transactions do not require explicit support on API level.
• The exception handling of the API should allow for application level error recovery strategies.
• Tracking of API usage should be supported by the API.
• Data replication between sites should be facilitated by the API.

Resources addressable by the API

Site, Job, Resource, User, Environment, Deployment, Notification

Overview of the supported operations

For the first version, the list of operations exposed by the API should be limited to the smallest set of operations required to conduct and monitor an experiment. Further operations will be added after a first feedback. As a reminder, the significance of HTTP methods is detailed below:

GET	fetch a representation of a resource (must be safe and idempotent)
POST	create a new resource
PUT	update a resource (must be idempotent)
DELETE	delete a resource (must be idempote

(Idempotent = multiple applications of the operation do not change the result)