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

Abierto
#3,615 1 comentario 3 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
38/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
java
Área
backend

Línea de trabajo

Comienza siguiendo ManagedInformerEventSource a través de InformerManager e InformerWrapper y, después, inspecciona InformerConfiguration y los puntos de entrada existentes AbstractInformerPool y ConfigurationServiceOverrider. Compara esas rutas con SharedIndexInformer.removeNamespaceIndex(). Se considera terminado cuando una opción de configuración de primera clase pueda deshabilitar el índice de espacio de nombres predeterminado sin requerir subclasificación experimental del pool, con cobertura del comportamiento de inicio del informer.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Java
Estrellas
944
Forks
242
Merge medio
1 d 4 h
PR fusionados (30 d)
43

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de operator-framework/java-operator-sdk

Todos los issues de operator-framework/java-operator-sdk

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.