Allow just registerPredicate for the polling to be overridden/configured for PerResourcePollingDependentResources
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 48/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- java
- Lĩnh vực
- backend-api-design
Hướng nghiên cứu
Bắt đầu bằng cách đọc PerResourcePollingDependentResource.createEventSource và PerResourcePollingConfigurationBuilder.withRegisterPredicate để hiểu thiết lập polling hiện có. Thêm hành vi pollingRegisterPredicate có thể ghi đè được mô tả trong issue, giữ nguyên hành vi polling mặc định hiện tại và ghi lại cách các register predicate tương tác với các bộ lọc informer và resource polling.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Is your feature request related to a problem? Please describe.
When using the PerResourcePollingDependentResource and you do not want polling (yet) for certain resources, it is hard to discover and cumbersome that you need to override the createEventSource method (which happens to be the only implemented method of that class) just to add the single line withRegisterPredicate(mypredicate::test) to the PerResourcePollingConfigurationBuilder-builder (which also happens to be the only configuration property that is not already out-of-the-box overridable when using PerResourcePollingDependentResource).
This has the additional downside that if the code for PerResourcePollingDependentResource.createEventSource is improved, we'd have to update our overridden method accordingly because we want the same behaviour, just only with the registerPredicate.
Describe the solution you'd like
A pollingRegisterPredicate method on PerResourcePollingDependentResource that could be overridden and by default returns null. Eg
@Override
protected Predicate<MyResource> pollingRegisterPredicate() {
return resource -> "someType".equals(resource.getSpec().type());
}
PerResourcePollingDependentResource could then use this method to configure the registerPredicate when setting op the polling event source.
Additionally, documenting the fact that by default polling is started for every resource (even if the depending reconciler has informer filters) and how this could be adjusted would greatly help new consumers.
Alternatively, an annotation @PollingRegisterPredicate could be added to your class that would then get picked up by PerResourcePollingDependentResource.
Describe alternatives you've considered
For our case (see below), it would also work if the polling picks up on the genericFilter/onAddFilter in the @ControllerConfiguration/@Informer annotations on the depending reconciler, so that the polling does not start if no event is processed by the reconciler.
We recognize that his may be too specific to our use case which may not apply to other people and is also more complex than exposing the existing registerPredicate a bit more which would also be more generic.
Additional context
Our use case is that we have a reconciler with a PerResourcePollingDependentResource which polls an external system. Our reconciler should only reconcile specific resources within a kind (eg based on a static type field). We achieve this by adding a genericFilter to the @ControllerConfiguration/@Informer annotation:
@ControllerConfiguration(informer = @Informer(genericFilter = PredicateClass.class) ...)
We noticed that, even for resources not being handled by the reconciler, polling was being started and the external system was being queried. This puts load on the operator and the external system for resource we know will never need something to happen in the external system.
This behaviour is not (clearly) documented and required some digging around to discover that PerResourcePollingConfigurationBuilder has the method withRegisterPredicate which to control this behaviour, but this method is not used by the PerResourcePollingDependentResource.
To use this register predicate, it's therefor required to override the createEventSource method of PerResourcePollingDependentResource, just to add the register predicate:
@Override
protected ExternalResourceCachingEventSource<MyInfo, MyResource> createEventSource(EventSourceContext<MyResource> context) {
return new PerResourcePollingEventSource<>(
resourceType(),
context,
new PerResourcePollingConfigurationBuilder<>(this, getPollingPeriod())
.withCacheKeyMapper(this)
.withName(name())
.withRegisterPredicate(resource -> "someType".equals(resource.getSpec().type())) // <--- only difference with original method
.build());
}
- Ngôn ngữ chính
- Java
- Star
- 944
- Fork
- 242
- Merge trung bình
- 1 ngày 4 giờ
- Pull request đã merge (30 ngày)
- 43
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ó 3/5 1-2 ngày Mức phù hợp với người mới 72/100
-
Độ 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 · 5 bình luận ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
operator-framework/java-operator-sdk#3617 · 1 bình luận ·
-
Độ 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 ·
Tất cả issue của operator-framework/java-operator-sdk
Issue tương tự
-
Bug Java Platform: Java
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
getsentry/sentry-java#6138 · 1 bình luận ·
-
bug needs triage p2
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
GoogleCloudPlatform/DataflowTemplates#4273 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
-
bug needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100