e78ba96949
Move the create_volume workflow to using taskflow and
split that workflow into three major pieces (each with
there own workflow) and create tasks that perform the
individual required actions to accomplish the pieces
desired outcome.
1. An api workflow composed of the following tasks:
- Extracting volume request (which checks types, values) and creates a
standard output for other tasks to work on (allowing further tasks to be
plugged in the chain without having to worry about other tasks output
formats).
- Quota reservation (rolled back on failure).
- Database entry creation.
- Quota committing.
- Volume RPC casting to volume scheduler or to targeted volume manager.
2. A scheduler workflow composed of the following tasks:
- Extracting scheduler request specification for further tasks to use.
- Change status & notify (activated only on failure).
- Create volume scheduler driver call (which will itself RPC cast to a
targeted volume manager).
3. A manager workflow composed of the following tasks:
- Extract volume request specification from incoming request for
further tasks to use. This also breaks up the incoming request into the 4
volume types that can be created later.
- Change status & notify on failure or reschedule on failure, this is
dependent on if rescheduling is enabled *and* which exception types are
thrown from the volume creation code.
- Create volume from specification
- This contains the code to create from image, create raw volume, create
from source volume, create from snapshot using the extracted volume
specification.
- Change status & notify success.
Key benefits:
- Handled exceptions in a easier to understand, easier to review and more
reliable way than they are currently being handled.
- Rescheduling is now easier to understand.
- Easier to understand structure with tasks that consume inputs, take some
action on them and produce outputs and revert on subsequent failure using
whatever they produced to know how to revert.
- Ability to add new unit tests that can test individual task actions by
providing mock task inputs and validating expected task outputs.
Future additions:
- Eventual addition of resumption logic to recover from operations stopped
halfway through.
- Ability to centrally orchestrate the tasks and pick and choice how
reconciliation of failures based on code or policies.
Part of bp: cinder-state-machine
Change-Id: I96b688511b35014a8c006e4d30b875dcaf409d93
8 lines
151 B
Plaintext
8 lines
151 B
Plaintext
[DEFAULT]
|
|
|
|
# The list of primitives to copy from taskflow
|
|
primitives=flow.linear_flow,task
|
|
|
|
# The base module to hold the copy of taskflow
|
|
base=cinder
|