skip the PodListeners lookup when the served Pod is being deleted
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 72/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- kubernetes, rust
調査の方向性
NodePublishVolume エントリポイントから開始し、証明書生成前に、提供対象の Pod の deletionTimestamp と PodListeners がどのように処理されるかを追跡します。既存の PodListeners 参照と証明書パスを確認し、削除中の Pod は参照をスキップする一方で、稼働中の Pod は現在の動作を維持し、listener SANs なしでマウントが完了することを確認します。
索引モデルが issue の本文から書いたものです。
説明
Problem
The secret-operator needs to read PodListeners in order to retrieve additional listener addresses to generate into the SAN field of certificates it creates. It has a long timeout waiting for these objects to appear, when a pod is spawned and requests the listener scope on certificates.
Especially during namespace deletion (maybe at other times as well) this can become a problem, when the PodListeners get deleted and the secret operator waits for them indefinitely. Since this is part of the NodePublishVolume step, this results in the Pod being stuck and holding pvc-protection.
Fix
In NodePublishVolume, if the Pod the volume serves has a deletionTimestamp, skip the
PodListeners lookup and issue the (throwaway) certificate without listener SANs so the mount can
complete. A Pod that is being deleted does not need listener-addressed certs.
The startup/steady-state path is unchanged: live Pods still wait for their listener addresses, so no
correctness regression and no startup race, the guard only relaxes behaviour for Pods already
marked for deletion.
- 主要言語
- Rust
- スター
- 13
- フォーク
- 8
- 平均マージ
- 1日 8時間
- マージ済み PR（30日）
- 10
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
stackabletech/secret-operator のほかの issue
-
type/bug
難易度 4/5 3〜5日 初心者へのやさしさ 45/100
stackabletech/secret-operator#754 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 48/100
stackabletech/secret-operator#753 · コメント 1 件 ·
-
customer-request type/bug
難易度 3/5 1〜2日 初心者へのやさしさ 38/100
stackabletech/secret-operator#666 · コメント 2 件 ·
-
customer-request type/feature-improvement
stackabletech/secret-operator#630 · コメント 7 件 · 担当者 1 名 ·
-
stackabletech/secret-operator#620 · コメント 2 件 · 担当者 1 名 ·
stackabletech/secret-operator の issue をすべて見る
似ている issue
-
Browser (wasm) relay client cannot connect to relays whose URL has a trailing-dot FQDN hostname オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
n0-computer/iroh#4550 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
paritytech/zombienet-sdk#591 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
farion1231/cc-switch#7638 · コメント 1 件 ·
-
onnx-ir re-exports ModelProto and GraphProto but not NodeProto, AttributeProto and AttributeType オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100