Listeners do not re-attach post deletion without podrestart
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 42/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- kubernetes, python
- 領域
- backend, networking
調査の方向性
Start by tracing how listener UIDs are assigned and how pod labels are matched to recreated listener services; the issue does not name specific files or tests. Reproduce the deletion and recreation scenario with a HiveCluster and a ClusterInternal listener, then check that the recreated service can reach the original ready pods without a pod restart.
索引モデルが issue の本文から書いたものです。
説明
Affected Stackable version
all
Current and expected behavior
Current behaviour
Assume a HiveCluster using a listener class e.g. ClusterInternal. A HiveCluster get's created with a listener discovered by label and IP provisioned by a volumeMount at the STS level.
If a Listener service gets deleted e.g. by hand or by e.g. only updating listener-operator, a new listener service gets created, the products operator does not reconcile and thus although pods are ready it fails to be reached via the fresh listener service.
Cause
Whenever a listener is recreated, it comes with a new UID. Pod's are labeled with something like listener.stackable.tech/mnt.<uid> referencing the listener UID created for this pod. Those UIDs change when a listener restarts and the pod don't. This mismatch will cause the pod being unavailable through it's listener address while becoming healthy and available
Expected behaviour
Listeners should reattach to its original pod after restart.
Possible solution
Probably something like a label which doesn't contain the UID.
Additional context
No response
Environment
No response
Would you like to work on fixing this bug?
None
- 主要言語
- Python
- スター
- 9
- フォーク
- 3
- 平均マージ
- 1日 6時間
- マージ済み PR（30日）
- 8
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
stackabletech/listener-operator のほかの issue
-
ListenerClass CRD restructure再び着手できるかも @NickLarsenNZ が 450 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
stackabletech/listener-operator#330 · コメント 5 件 · リアクション 1 件 · 担当者 1 名 ·
-
OpenShift Route backend再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープン
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
-
customer-request
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
stackabletech/listener-operator#302 · コメント 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 20/100
-
Rename `listeners.stackable.tech/listener-class` PVC annotation to `listeners.stackable.tech/class`オープン
難易度 3/5 1〜2日 初心者へのやさしさ 43/100
stackabletech/listener-operator#271 · コメント 1 件 ·
stackabletech/listener-operator の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
deepchem/deepchem#5289 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 75/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 60/100
UKGovernmentBEIS/inspect_evals#2892 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
Versioning docs: say that no output from the 0.46 warning check means nothing is affected対応中かも @grelinfo が今日担当しました。 オープンdocumentation priority:low size:S
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
alphacrack/readme2demo#293 ·