WorkerDeployment 0.5.0

このFormはModuleWorker 0.3.0一つの有効な WorkerVersion 0.5.0または WorkerVersion 0.6.0の集合を選ぶ。forms.takoform.com/v2の Resourceであり、公開endpointやcronそのものを作らない。複数Versionへの配分は新たなイベントを選ぶ規則であって、進行中の実行、Actorの永続store、Workflowの履歴を移行しない。

入力と参照

specはworkerとversionsだけを必須とする。workerはModuleWorker 0.3.0の {"resourceUid":string}参照である。versionsは1〜8件の {"workerVersion":{"resourceUid":string},"weight":integer}の配列で、 weightは1〜10000 basis point、総和は正確に10000とする。同じVersion UIDを二度書けず、0 weightは省略で表す。配列順は選択確率に影響しない。既定値はない。 specと全入れ子の未知キー、null、小数、負数、範囲外、重複を拒否する。秘密入力はない。同一specの比較ではversionsをVersion UID順の集合として扱い、配列順とobjectのキー順は無視する。同じUID・weightの全組が等しければ同一specであり、weightの変更は更新である。

全トラフィックを一版へ割り当てるspecの例（UIDは説明用）:

json

{
  "worker": { "resourceUid": "worker-uid" },
  "versions": [
    { "workerVersion": { "resourceUid": "version-uid" }, "weight": 10000 }
  ]
}

Hostは各参照が同じHost・Spaceに存在し、要求者が利用を認可され、Form URLが上記の版に完全一致することを副作用前に検証する。Versionは0.5.0または0.6.0の上記exact URLだけを許し、 0.5.0を0.6.0へ変換しない。各Versionのspec.worker.resourceUidはこの Deploymentのworker.resourceUidと一致しなければならない。Version UIDを保存し、名前や「最新」から再解決しない。一つのWorkerに有効なDeploymentは高々一つである。この0.5.0と旧WorkerDeployment 0.4.0を跨いで同じsingle-active所有を検証し、別Formだからという理由で同時に有効化してはならない。先に旧Deploymentを削除してから新しいDeploymentを作る。これは既存UIDの自動Form移行ではない。

選択と成立条件

Hostは新たなHTTP要求、scheduled、queue、Actor event、Workflowの新しい実行contextを受理する時点の有効な配分からVersionを一つ選び、その一つを当該invocationの終了まで固定する。配分はbasis pointの比率であり、個別requestに決定的なhash結果や短期の正確な件数を保証しない。 Worker Versionを選択できなければ別のVersionへ黙ってfallbackしない。Clientに見える失敗は該当するhandler/Binding契約による。新しい配分は受理後の実行にだけ適用し、既存のHTTP stream、 Actor event、Workflow contextを途中で切り替えない。Actorの次のeventとWorkflowの次の retry/wakeは、その時点の配分を再選択できる。

ready:trueとして有効化する前にHostは全weighted Versionの指定済みbundle、handler、 asset、Binding、必要な秘密を確認する。添付されたEndpoint/CustomDomainまたはこのWorkerを宛先とするservice Bindingがある場合、到達し得る全Versionは宣言・export済みfetchか検証済みassetsのいずれかでHTTP要求へ応答できなければならない。 cron/queue consumerが要求するhandlerは、到達し得る全Versionが宣言・exportしなければならない。添付後のDeployment作成・更新、または後からのAttachment作成・更新でも同じ全weighted Versionの条件を検証し、欠ける構成を有効にしてはならない。同じWorkerを参照する削除未完了のActorNamespaceとDurableWorkflow（作成Operationを受理済みのものを含む）の全classNameを各Versionが正しいprototype ABIで提供しなければならない。Namespace/Workflowの作成と、このDeploymentの作成・配分更新は、受理済みで未完了のOperationを含めて整合性を保つ。後から作るNamespace/Workflowは現在の有効配分を不適合にしてはならず、その作成を409 dependency_conflictで副作用前に拒否する。両方が成功すると不適合な配分が有効になる組合せを認めない。Hostはこの整合性を実装方法に依存せず守る。作成・更新の受理後に並行変更との衝突が確定した場合も、不適合な配分を有効化せず、その受理済みOperationの結果と残存効果を共通Host API v2に従って報告する。受理済みOperationを後からHTTPの事前拒否へ置き換えない。 Workflowのstep name・効果・出力について新旧コードの履歴互換性は作者の責任であり、Hostは既知の不整合を検出したら有効化を拒否し、検証できないことを互換性の証明として扱わない。 Hostは移行・履歴書換え・Actor store初期化で不整合を隠さない。参照先の後続削除や秘密消失で Readyが崩れたら新規受理を拒否し、残存状態を観測可能にする。

状態と操作

未観測のobservedは {}。確認済みならready:boolean、active:boolean、 selectedVersions（{"resourceUid":string,"weight":integer}の配列）を返す。 active:trueは、このDeploymentがそのWorkerの新しいinvocationの選択元であることを表す。 readyは有効化可能性の観測であり、各requestや外部到達性の成功保証ではない。 observedAt/observedGenerationは共通APIの時点を示す。outputは {}。

作成では参照と条件を検査し、一つのWorkerの有効配分として原子的に設置する。別の有効 Deploymentがある場合は置換せず拒否する。依存先が準備中なら受理したOperationは状態を明示して待つことができるが、Readyでない配分へトラフィックを流さない。
取得は最後に確認した配分と状態を返す。管理記録がある間は実行先の一時的な不在を 404に置き換えない。
更新はspec全体を置換する。workerは不変で、変えるには別Deploymentを作る。 versionsは全件指定し、Hostは新集合を検証してから一度に切り替える。途中の部分配分を公開しない。同一specの新しいキーのPUTも新しいOperation/generationで再照合する。旧weightから外れたVersionには切替後の新規invocationを割り当てない。既存contextは固定Versionで完了できるが、切替から15分を超えて残るcontextはHostが取消し、streamを閉じ、childの物理的退役を確認する。この退役は新配分の有効化を妨げないが、古いVersionの削除は退役が済むまで拒否する。Host障害時は所有記録から再開し、退役未確認を完了扱いしない。
削除はまず新たなHTTP要求・scheduled・queue・Actor event・Workflow contextの選択を閉じる。既存invocationには取消signalを送り、HTTP body/Actor upgrade予約とHost所有streamを止め、 child実行の物理的退役と古いownerのfenceを確認してから成功にする。Promise rejectionだけを退役の証明としない。Hostが確認できない間はOperationを未確定として照合を続ける。削除後はDeploymentなしでActor alarm/socket callbackやWorkflow wakeを新規配送しない。 Actorのstore・alarm・socket identity、Workflow instance・履歴は各Resourceに残すが、旧Version UIDへのlive context参照は残さない。Worker/Versionや添付先Resourceを連鎖削除しない。

結果が不明な作成・更新・削除は元のIdempotency-Keyと要求を再送し、Operationと実行先を照合する。タイムアウトから成功・失敗を推定して別のDeploymentを作らない。参照先の所有者は参照先FormとHostであり、Deploymentはそのコードやdataを所有しない。未知フィールドを受け入れる拡張や意味の変更には新しいForm URLを使う。

通常の後始末は、まずendpoint・cron・queue consumer等の入口を削除し、次にこのDeploymentを削除して実行を退役させ、不要なVersionを削除し、そのVersionのBinding参照が消えてから ActorNamespace/Workflowを削除し、最後にWorkerを削除する。Namespace/Workflowの休眠dataを消すのは各Resourceの明示的なDELETEであり、Deployment DELETEの連鎖副作用ではない。

WorkerVersion 0.6.0のcontainerBindingsはContainerのexact UID/認可/routeを検証してから選択可能にする。新規Container callのgeneration選択と30秒drainはContainer本文に従い、このDeploymentのWorker contextの15分退役期限で延長しない。 Deploymentの削除はContainerへの新規callerを閉じて残存I/Oを取消するが、Containerそのものやその独立dataを連鎖削除しない。Binding依存はVersionの明示DELETEまで残る。

WorkerDeployment 0.5.0 ​

入力と参照 ​

選択と成立条件 ​

状態と操作 ​

WorkerDeployment 0.5.0

入力と参照

選択と成立条件

状態と操作