Listeners do not re-attach post deletion without podrestart
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 42/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- kubernetes, python
- Lĩnh vực
- backend, networking
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- Python
- Star
- 9
- Fork
- 3
- Merge trung bình
- 1 ngày 6 giờ
- Pull request đã merge (30 ngày)
- 8
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Không có hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của stackabletech/listener-operator
-
ListenerClass CRD restructureCó thể làm lại được @NickLarsenNZ đã nhận 450 ngày trước và không có pull request nào đang mở. Đang mở
stackabletech/listener-operator#330 · 5 bình luận · 1 reaction · 1 người được giao ·
-
OpenShift Route backendCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
-
customer-request
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
stackabletech/listener-operator#302 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 20/100
-
Rename `listeners.stackable.tech/listener-class` PVC annotation to `listeners.stackable.tech/class`Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 43/100
stackabletech/listener-operator#271 · 1 bình luận ·
Tất cả issue của stackabletech/listener-operator
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
deepchem/deepchem#5289 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
Pull Request for pretty_macĐang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 75/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 60/100
UKGovernmentBEIS/inspect_evals#2892 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Versioning docs: say that no output from the 0.46 warning check means nothing is affectedCó thể đã có người làm @grelinfo đã nhận hôm nay. Đang mởdocumentation priority:low size:S
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
alphacrack/readme2demo#293 ·