read-cache-after-write consistency and event filtering for deletes
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 20/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- java, kubernetes
- Lĩnh vực
- backend, distributed-systems
Hướng nghiên cứu
Bắt đầu bằng cách xác định các đường dẫn read-cache và lọc sự kiện cho các thao tác xóa trong Java Operator SDK, sau đó xem lại issue cha để biết hành vi dự kiến. So sánh các tài nguyên có và không có finalizers, cùng với ghi chú về optimistic locking; issue này chỉ hoàn tất sau khi chính sách lọc sự kiện xóa được quyết định và triển khai nhất quán.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
See also parent issue.
This might be a bit problematic, for resource without finalizer:
If the resource does not implement a finalizer, we could just record the UID of the resource and filter out events until we receive the delete event, that removes the cached resource ID.
The issue is with the resources with a finalizer, there we could define this like:
-
Filter just the event that was caused by the delete operation (in this case, it just adds the deletion timestamp), and process subsequent events. By definition, only operations should happen afterwards, and that includes finalizer removals, but that is not enforced on the API level. Note that implementation-wise, this is an issue since the delete operation does not return the new resource nor it's version.
-
We could filter out all the subsequent events until we receive a delete event. - But this might be too opionated, and especially if the controller would be restarted, users might see the resources again (although still marked for deletion). So probably not the right thing to do.
Notes:
- optimistic locking does not seems to work for deletes either
- Ngôn ngữ chính
- Java
- Star
- 944
- Fork
- 242
- Merge trung bình
- 1 ngày 14 giờ
- Pull request đã merge (30 ngày)
- 46
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 operator-framework/java-operator-sdk
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
operator-framework/java-operator-sdk#3621 · 8 bình luận · 1 người được giao ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 38/100
operator-framework/java-operator-sdk#3615 · 1 bình luận · 3 reaction ·
-
Set baseline Java version to 21 Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 45/100
operator-framework/java-operator-sdk#3568 · 1 bình luận · 1 reaction ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
-
Support for Virtual Threads Đang mở
operator-framework/java-operator-sdk#3538 · 2 bình luận · 2 người được giao ·
Tất cả issue của operator-framework/java-operator-sdk
Issue tương tự
-
executions.Query — startDate and timeRange filters are sent with inverted comparison operators Đang mởarea/plugin
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
kestra-io/plugin-kestra#190 ·
-
litertlm-android AAR ships no consumer ProGuard rules → "mid == null" SIGABRT in minified apps Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
google-ai-edge/LiteRT-LM#3739 ·
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
Add canonical URLs and a sitemap Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
integra-team-red/meet-map#249 ·
-
[Studio][Bug] Cancelled create-user dialog keeps the password and admin switch for the next attempt Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
apache/rocketmq-dashboard#5064 ·