Glance-tasks-api

Overview

This proposal unifies the new upload workflow , new download workflow , and image cloning blueprints in an extensible, consistent, and easy-to-learn way.

General Workflow

1. User posts a request to /v2/tasks
2. Glance returns a 201 with Location: /v2/tasks/{task-uuid}
   • The resource at /v2/tasks/{task-uuid} will be an expirable entity
3. User polls /v2/tasks/{task-uuid} for status information on the requested task
4. 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
   • the expiration datetime of the tasks resource itself

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, type, 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 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",
                "preparing",
                "transferring",
                "processing",
                "verifying",
                "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

1. What do we return when a user makes a GET for a task UUID that exists, but they don't own?
   • 401 or 404?

Proposed Tasks

1. import
2. export
3. clone

Related

• Havana summit discussion etherpad (see bottom of pad)
• original blueprint proposal
• mailing list discussion of original proposal