Bug 1041823

Summary: [RFE][glance]: Add "task" to track the lifecycle of image actions
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/glance/+spec/task-of-image-action
Whiteboard: upstream_milestone_none upstream_status_unknown
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 17:32:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description RHOS Integration 2013-12-12 19:30:08 UTC 
Cloned from launchpad blueprint https://blueprints.launchpad.net/glance/+spec/task-of-image-action.

Description:

By current implement, Glance will "kill" the image if there is a upload failure. And end user can't see the image anymore if the image state is marked "killed". So instead of "killing" an image when something goes wrong during data upload, we need a better way to let end user query the image failed to upload and notify the user. More info, please refer this link: https://blueprints.launchpad.net/glance/+spec/image-error-state-management

Based on the discussion with markwash, we prefer to add "task" instead of a new "error" state to track the life cycle of image actions. And one of the reasons is "error" state means the image is in an "unrecoverable" state.  But in real, the image create action should be able continue by retry/re-upload.

So a typical work flow maybe like below:
1. User submit a command that processes asynchronously to Glance, in the return response there should be /v2/tasks/<id>.
2. User can do GET /v2/tasks/<id> to track the status of this action, including find out any errors
3. The task will be persist. 
     3.1 If the action is executed successfully.
     3.2 If the action failed, the error log will be saved, including the error details. 

For now, Nova is using "action" and "fault" to resolve this kind of issue, so it can be referenced for this design.

Specification URL (additional information):

None