Idle CU sweep cannot reclaim a computing unit whose execution is stuck in a non-terminal state
メンテナーはふだん 1 日以内に返信
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 38/100
- issue の種類
- 機能追加
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- kubernetes, scala
調査の方向性
Start with ComputingUnitHelpers.reconcileVanishedKubernetesUnits and the idle Kubernetes computing unit sweep, then trace how workflow_executions status and last_update_time are used. Compare the existing listing-triggered reconciliation with the proposed scheduled pod-state check. Done means a live pod with a stale non-terminal execution no longer keeps an idle computing unit unreclaimed.
索引モデルが issue の本文から書いたものです。
説明
Feature Summary
Follow-up to #6046.
Problem
The idle Kubernetes computing unit sweep treats a computing unit as busy whenever any of its
workflow_executions rows carries a non-terminal status code (status NOT IN (3, 4, 5)). That
test has no time bound, so an execution row left stuck in a non-terminal state keeps its computing unit off the sweep indefinitely, even though the unit is doing no work.
But the problem is, nothing else reclaims it either: ComputingUnitHelpers.reconcileVanishedKubernetesUnits only
runs when someone calls a listing endpoint, and it only checks whether the pod is already gone,
not whether the execution row is stuck somewhere. A live pod with a stuck row is missed on both paths.
maptoStatusCode also maps UNKNOWN (and TERMINATED) to -1, which is not in {3,4,5}. A row whose final status is -1 pins its unit off the sweep permanently. Fixing that means changing the codes amber writes, not this sweep's predicate.
Proposed Solution or Design
- Ignore a non-terminal execution row whose
last_update_timeis older than its own timeout. - Check execution status codes against actual pod state on a schedule, rather than only on a
listing request.
Either is a larger change than #6046 should carry, hence this follow-up.
Affected Area
No response
- 主要言語
- Scala
- スター
- 322
- フォーク
- 195
- 平均マージ
- 2日 19時間
- マージ済み PR（30日）
- 142
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
apache/texera のほかの issue
-
Search bar autocomplete stops working after a model appears in the suggestions対応中かも @aglinxinyuan が 21 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
apache/texera#8700 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
apache/texera#8682 · コメント 5 件 ·
メンテナーはふだん 1 日以内に返信
-
JSONL File Scan reads a JSON null as the text "null"対応中かも @CaroFernando が 19 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
apache/texera#8674 · コメント 1 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
-
LARGE_BINARY test leaves a real S3 object behind on every S3-reachable run対応中かも @ShawnGarello が 4 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
メンテナーはふだん 1 日以内に返信
-
Missing workflow returns 500 from workflow type endpoint再び着手できるかも @VuMartin が 44 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
apache/texera#8300 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
似ている issue
-
scope:security type:aquasec
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
AbsaOSS/atum-service#494 ·
-
Send camera_pitch and camera_roll to the AI API so validator crops can be tilt-corrected対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンAI Auto-validate
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
ProjectSidewalk/SidewalkWebpage#5788 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
A-network C-bug S-ready-for-human
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
ergoplatform/ergo#2741 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 78/100
scalameta/metals-zed#99 ·
-
area:ops priority:P2 status:idea
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
KD5UJC-XYZ/scarab#112 ·