Integrate persistence support of taskflow for managing create volumes tasks
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/
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
- Started by
- Completed by
- Sean McGinnis
Related branches
Related bugs
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:/
Addressed by: https:/
Integrate persistence support of TaskFlow
Gerrit topic: https:/
Addressed by: https:/
Common changes for TaskFlow's persistence support