【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 可以輕松地對那些被 stop\kill 命令打斷的 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 難以理解，調試和檢查；
通過 status\progress 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 使用和期望能力的一種；