【Summary】
TaskFlow 是一个为了 openstack 实现的 python 库，使得执行 task 变得简单，一致，易扩展，可靠；
它能以一种声明的方式，将轻量级 task 对象的创建与 flows 结合起来；
它以一个可以声明的方法可以使得其包含的 engines 去运行这些 flows，这些 flow 可以被停止，继续，或者是安全回滚；
使用 TaskFlow 可以享受以下特性：
更多的弹性状态；
自然声明构造；
更易于测试（由于 task 包括且只包括一件事）；
工作流插件化；
容错性；
简化 crash 后的恢复；
【Why TaskFlow?】
如今 openstack 代码已经有组织的增长，但是对于去操作序列化的代码，没有一个标准和一致的方法，使得当调用过程意外被终止时，代码流程可以安全的继续或者回滚；
大多数 projects 甚至没有让 tasks 可重启与可恢复；
简单的跳过或者恢复的场景在如今的代码里已经几乎不可能；
Task 可以轻松地解决这些问题；
【Conceptual example】
下面这段伪代码描述了一个 flow 是如何像 sql 事务一样工作的；
START TRANSACTION
task1: call nova API to launch a server || ROLLBACK task2: when task1 finished, call cinder API to attach block storage to the server || ROLLBACK ...perform other tasks... |
COMMIT
【Service stop/upgrade/restart (at any time)】
在组件运行时，openstack 的一个典型的问题是，当 daemon 被强制 stop 时（比如升级，硬件故障，维护中以及其他一些原因），daemon 会发生什么；
service stop [glance-, nova-, quantum…]
现在许多 openstack 的组件没有处理强制 stop，使得把系统状态置于一个可调解的状态中；
典型的操作是当一个 service 执行时，被瞬间强制 stop，不能被恢复而且在某种程度上会被遗忘（后续一个 scanning 进程可能会尝试清理这些孤儿资源）；
在这种情况下，Taskflow 会通过追踪这些 actions, tasks 和他们有关的 states 使得当 service 被 restart（甚至 upgrade 之后） 的时候，service 可以轻松地对那些被 stopkill 命令打断的 tasks 继续或者回滚；
这将有助于一个容错性的架构，避免孤儿资源，减少将来的 daemon 进程去尝试清理相关工作的需要；
【Orphaned resources】
由于缺少事务的语义，许多 openstack 的 projects 会使 resource 处于一个孤儿状态，或者称作 ERROR 状态；
如果 openstack 被自动化系统（比如 Heat）驱动，那么这在很大程度上是不可接受的，它无法分析出哪些孤儿资源需要被清理；
Taskflow 通过提供以 task 为导向的模型，使得语义可以被用作正确地追踪资源的修改轨迹；
这使得所有在一个（或一组）资源可以自动地被解开，以保证没有资源被遗漏；
【Metrics and history】
当 openstack 的 services 被结构化为 task 和 flow 对象与模式以后，它们能够自动轻松地为 service 添加 metric reporting 和 action history，只需运行一个 task 或者 flow 时，通过 taskflow 去记录 metric 或者 history 就行了。
在各个 openstack service 中，对于实现这个类似的特性有着各自的方法，但是通过 taskflow 这些不同的方法会变成一个统一的方法；
开发者使用 taskflow 不需要关心 taskflow 如何记录的这个信息；
这帮助将 metric & history 与 task 和 flow 的有关的代码同真正定义 task 和 flow 的 action 的代码分离开；
【Progress/status tracking】
在许多 oepnstack 的项目里，需要尝试去展示这个项目的动作执行情况；
不幸的是，这个需求在不同的项目中实现也是不同的，从而导致不一致和进度状态的汇报或者追踪不是那么的准确；
Taskflow 提供了一个底层的机制，通过让你自己在 taskflow 内置的 notification 系统里面插入与添加，使得追踪进程更加简单；
这避免了在 action 中添加代码，在 action 中添加代码是不好的，那样会使 action 难以理解，调试和检查；
通过 statusprogress tracking 的代码与真正操作 action 的代码解耦，同样使得进度状态机制在将来的改动中更加弹性化；
······【Structure】
【Atoms】
atom 是 taskflow 中的最小执行单位，作为其他 class 的基类；
atom 有自己的 name 和 version；
atom 需要为自己的输入参数和输出参数进行命名；
【Tasks】
task 是一个关于可以执行或者回滚的有关 work 的操作序列；（类似于一个 function）
task object 继承于 BaseTask，一个定义了 task 必须提供的属性项与方法的类；
现在提供两种 task 的子类：
Task：自己继承并创建 subclass；
FunctorTask：封装已经存在的 function 到 task object 里；
【Retries】
retry 是从 atom 派生的一个特殊的 work 单位，可以处理错误，控制流的执行以及通过配置必要的参数尝试其他的 atoms；
当一个相关的 atom 失败，这些 retry unit 会被询问，从而决定解决的策略；
目标是使得 retry atom 通过这个询问， 可以提供一个解决这个 failure 的策略；（可能是通过重试，回滚一个单独的 atom，或者回滚和这个 retry 相关的代码）
继承这个 retry 的 base class 必须提供一个叫 on_failure 的方法，去决定应该如何去处理一个 failure;
【Flows】
flow 是一个可以将一个或多个 tasks 以一个有序的顺序链接到一起的结构；
当 flow 回滚时，它对每一个子 tasks 执行回滚的代码，使用各自 tasks 已经定义好的 reverting 机制；
【Engines】
task 如何从 pending 状态到 failed 或者 success 状态；
目的是可靠地运行你的 workflow，处理这些控制和执行流；
这使得使用 taskflow 库的代码只需要担心 workflow 的形式，而不需要担心执行，回滚和恢复；
【Jobs】
如何对 tasks 和 flows 提供高可用和可扩展，保证将来的进程无论发生多少 crash 和 failure，机器运行工作负载正常；
这个概念使得使用 taskflow 进行编码不需要担心分布式和对 workflow 的高可用；
【Conductors】
即插即用的方式，对于一个个体，不同的概念去使用运行时间单元；
【States】
一个 flow 或者一个 task 可能经历的潜在的状态变化；
【Notifications】
如何获取关于状态变化，任务结果，任务进度，工作提交以及其他；
【Reversion】
tasks 和 flows 均可以通过执行相关 task 对象的 rollback 代码来实现回滚；
比如，如果一个 flow 被要求创建一个带有块存储 volume 的 server，通过包含两个 tasks；
task1: create server || rollback by delete server
task2: create+attach volume || rollback by delete volume
如果 attach 操作失败，flow 中所有的代码会被回滚，导致创建出来的 server 和 volume 都会被删掉；
【Persistence】
taskflow 可以保存当前 atom 的状态，进度，参数和结果，flow、job 以及对于数据库的操作也可以，这使得 flow 和 atom 的 resumption, check-pointing 和 reversion；
一个持久化的 api，以及一个持久化的 base 类型，使用了 taskflow 提供的方法，目的是保证 jobs，flows 和那些相关的 atoms 可以在数据库或者内存中做 backup；
【Resumption】
如果一个 flow 被启动，但是在完成前被打断了，这个 flow 会在它上一个 checkpoint 安全的继续；
它允许对服务进行安全和简单的 crash recovery；
Taskflow 对 checkpoint log 提供了不同的持久化策略，使你作为一个 application 开发者可以挑选适合 application 使用和期望能力的一种；