Integrate persistence support of taskflow for managing create volumes tasks

Registered by Abhishek Kekane

There are few corner cases where the volume is left in unrecoverable state and it is not possible to delete the volume without administrator’s intervention.

API workflow:
A) Before committing the quota, volume entry is added to the database, at this point if cinder-api goes down, then the state of the volume remains in the “creating” status forever.
B) After quota is committed if cinder-api goes down, then the state remains in the “creating” status forever.
User is not allowed to delete the volume if the state of the volume is in “creating” status.

Manager workflow:
Above same issue is observed when the cinder-volume service goes down before it actually creates a volume, the state of the volume remains in the “creating” status and user won’t be allow to delete the volume. This problem can be solved by adding code in the init_host of cinder/volume/manager.py by marking all volumes in "creating" status to "error" status so that user will then be able to delete the volume.

Problem:
Administrator's intervention is required to cleanup the volume left in unrecoverable state.

In a real production environment, whenever any services goes down, it will be notified immediately and a corrective action will be taken spontaneously to start the service again. But at present, there is no provision to resume pending task flows after service restarts as the state of the task flows are not persistent. Taskflow team has added persistence support lately so now it is possible to maintain the task state in the database. When the service restarts it will get all of the pending taskflow and resume it from the last known point.

Blueprint information

Status:
Complete
Approver:
John Griffith
Priority:
Undefined
Drafter:
Abhishek Kekane
Direction:
Needs approval
Assignee:
Rajesh Tailor
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Sean McGinnis

Related branches

Sprints

Whiteboard

(smcginnis): Marking obsolete as this has been sitting out there for a long time. If this is still needed, please submit a new bp.

@Abhishek
Could you please submit a cinder-spec proposal for this work and include some detail on how you want to implement this? The description here is a great summary of the problem to try and solve, but the solution here is simply "use persistent task-flow", I'd like to see considerably more detail about the solution being proposed and what it involves as well as why it's the right way to go.

You should not set a milestone target unless the blueprint has been properly prioritized by the project drivers.

Gerrit topic: https://review.openstack.org/#q,topic:bp/create-volume-persistence-taskflow-support,n,z

Addressed by: https://review.openstack.org/147879
    Integrate persistence support of TaskFlow

Gerrit topic: https://review.openstack.org/#q,topic:bp/create-volume-persistence-taskflow-support-scheduler,n,z

Addressed by: https://review.openstack.org/152198
    Common changes for TaskFlow's persistence support

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.