Glance-tasks-api
Contents
Overview
This proposal unifies the new upload workflow [1], new download workflow [2], and image cloning [3] blueprints in an extensible, consistent, and easy-to-learn way.
General Workflow
- User posts a request to /v2/tasks
- Glance returns a 201 with Location: /v2/tasks/{task-uuid}
- The resource at /v2/tasks/{task-uuid} will be an expirable entity
- User polls /v2/tasks/{task-uuid} for status information on the requested task
- Eventually, when the task is completed, the resource will contain
- task result information, e.g.,
- if the task was successful, the location of the result of the task
- for import or clone tasks, this will be an /images resource
- for export, it will be a location where the exported item may be retrieved
- if the task was not successful, an informative message
- if the task was successful, the location of the result of the task
- the expiration datetime of the tasks resource itself
- task result information, e.g.,
Task Entities
An task entity is represented by a JSON-encoded data structure.
An task entity has an identifier (id) that is guaranteed to be unique within the endpoint to which it belongs. The id is used as a token in request URIs to interact with that specific task.
An task is always guaranteed to have the following attributes: id, task_type, task_status, and self. The other attributes defined in the task schema below are guaranteed to be defined, but will only be returned with a task entity if they have been explicitly set.
Note: the task entity will need to have an "owner" field (whether or not it's exposed in the response) so that we can make sure that users can't see each other's tasks.
Task Properties
(no ordering, just using the numerals to keep count)
- id
- owner
- task_type
- task_status
- expires_at
- message
Task Schema
A json-schema for the task entity will be available at the URI /v2/schemas/tasks
And it goes a little something like this:
{ "name": "task", "properties": { "id": { "description": "An identifier for the task", "pattern": "^([0-9a-fA-F]){8}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){4}-([0-9a-fA-F]){12}$", "type": "string" }, "owner": { /* not sure if we really need this property */ "description": "An identifier for the owner of this task", "type": "string" }, "task_type" : { "description": "The type of task represented by this content", "enum": [ "import", "export", "clone" ], "type": "string" }, "task_status" : { "description": "The current status of this task.", "enum": [ "queued", "processing", "success", "failure" ], "type": "string" }, "expires_at": { "description": "Datetime when this resource is subject to removal", "type": "string", "required" : false }, "message": { "description": "Human-readable informative message only included when appropriate (usually on failure)", "type": "string", "required" : false, } }, "links": [ { "href": "{self}", "rel": "self" }, { "href": "{file}", "rel": "enclosure" }, { "href": "{schema}", "rel": "describedby" } ], }
Actually, it may be better to just use this as a proto-schema and define a specific one for each task type, available at, e.g.,
- /v2/schemas/tasks/import
- /v2/schemas/tasks/export
- /v2/schemas/tasks/clone
OK, you've got the basic idea. I realized I'm doing this backwards. The decision about whether each task gets its own schema or whether they can be combined into a single schema, or a single schema that references another schema to give the details for that kind of task should wait until after we've figured out what each task looks like. Same deal with the requests/responses.
Task Request Body
The basic tasks request will be Content-type: application/json and will look something like this:
{ "task-type": "{task-name}", "task-info": { /* content will depend on the task type */ } }
Or there may be a different one for each task, still working on this.
Task Response Body
The basic tasks response will be Content-type: application/json and will adhere to the json schema described above.
Requests
Create a Task
POST /v2/tasks
Request body must be appropriate for the task_type.
Display Task Detail
GET /v2/tasks/{task_id}
Returns a task response as defined above.
List Tasks
GET /v2/tasks
Returns a list of tasks owned by the user making the request.
Query Parameters
We'll want to allow filtering on the task_type, e.g.,
GET /v2/tasks?task_type=import
would return all non-expired import tasks owned by the user making the request.
Open Questions
- What do we return when a user makes a GET for a task UUID that exists, but they don't own?
- 401 or 404?
- The task request will return a 200 even when the task_status is 'failure' (since the task response itself is being returned OK). Some of these failures will be for things like not-found, format-not-supported, conflict ... this will be mentioned in the 'message' field, but do we want to have a separate failure code or something to make it easier for an API user to extract this info?
Proposed Tasks
Related Documents
- Havana summit discussion etherpad (see bottom of pad) [7]
- original blueprint proposal [8]
- mailing list discussion of original proposal [9]
References
- ↑ https://wiki.openstack.org/wiki/Glance-tasks-import
- ↑ https://wiki.openstack.org/wiki/Glance-tasks-export
- ↑ https://wiki.openstack.org/wiki/Glance-tasks-clone
- ↑ https://wiki.openstack.org/wiki/Glance-tasks-import
- ↑ https://wiki.openstack.org/wiki/Glance-tasks-export
- ↑ https://wiki.openstack.org/wiki/Glance-tasks-clone
- ↑ https://etherpad.openstack.org/havana-getting-glance-ready-for-public-clouds
- ↑ https://blueprints.launchpad.net/glance/+spec/upload-download-workflow
- ↑ http://lists.openstack.org/pipermail/openstack-dev/2013-May/009385.html