【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

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 使用和期望能力的一種；