Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Allow disabling or removing the default namespace index of an event source's informer

Đã đóng
  • Có gì không ổn?
#3,615 1 bình luận 3 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

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
38/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
backend

Hướng nghiên cứu

Bắt đầu bằng cách lần theo ManagedInformerEventSource qua InformerManager và InformerWrapper, sau đó kiểm tra InformerConfiguration cùng các entry point hiện có là AbstractInformerPool và ConfigurationServiceOverrider. So sánh các đường đi đó với SharedIndexInformer.removeNamespaceIndex(). Công việc được xem là hoàn tất khi một tùy chọn cấu hình hạng nhất có thể vô hiệu hóa namespace index mặc định mà không yêu cầu subclassing pool mang tính thử nghiệm, với độ bao phủ cho hành vi khởi động của informer.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

For InformerEventSources, fabric8's default "namespace" index is unused: InformerWrapper.list(namespace) filters the item store directly, and byIndex only serves the JOSDK-qualified custom indexes. The index still costs one entry per object in the watched scope, and when an event source uses a filtering ItemStore to bound its cache, this unused index becomes the dominant retained memory (compounded by the fabric8 cleanup gap reported in fabric8io/kubernetes-client#8103).

fabric8 already exposes SharedIndexInformer.removeIndexer(String), but the SDK offers no path to the informer (it sits behind ManagedInformerEventSource's InformerManager and InformerWrapper, all inaccessible), so today the only way is reflection over three private fields (see the edit below, the experimental informer pool provides a path).

Suggestion: an InformerConfiguration flag (e.g. withoutNamespaceIndex()) applied when the wrapper starts the informer, or an extension point that hands advanced users the SharedIndexInformer for tuning.

Would you be open to a PR for this, and which of the two shapes would you prefer?

EDIT: found out that overriding AbstractInformerPool.start (via ConfigurationServiceOverrider.withInformerPool) allows calling SharedIndexInformer.removeNamespaceIndex() before the informer starts, so reflection is not required after all. The API is marked experimental though, and subclassing the pool for a per-informer concern is indirect, so we think a first-class InformerConfiguration option is still worth it. Happy to include that context in the PR.

Ngôn ngữ chính
Java
Star
943
Fork
245
Merge trung bình
2 ngày 58 phút
Pull request đã merge (30 ngày)
46

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của operator-framework/java-operator-sdk

Tất cả issue của operator-framework/java-operator-sdk

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.