HelmRepository: use conditional HTTP requests (ETag / If-Modified-Since) when fetching index.yaml
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- go, kubernetes
- Área
- backend, performance
Línea de trabajo
Comienza en internal/helm/repository/chart_repository.go, en CacheIndex y DownloadIndex, y luego sigue la decisión de no-op en internal/controller/helmrepository_controller.go alrededor de las líneas 464-468. Verifica cómo se pueden conservar los validadores de respuesta por objeto y cómo un 304 llega a la ruta existente para contenido sin cambios sin leer el body. Se considera terminado cuando se usan requests condicionales cuando existen validadores, mientras que los repositorios sin validadores mantienen el comportamiento actual.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Problem
For HTTP(S) HelmRepository objects, source-controller downloads the full index.yaml on every reconcile interval, unconditionally: CacheIndex → DownloadIndex issues a plain GET, and only after the download completes is the digest compared against the current artifact to decide the reconcile is a no-op (helmrepository_controller.go#L464-L468). There is no If-None-Match / If-Modified-Since anywhere in the fetch path (the only ETag references in the codebase are the S3/GCS test mocks).
Real-world indexes are large (grafana ~2 MB, prometheus-community ~4 MB, bitnami historically >10 MB), and the cost is linear in the number of objects: N HelmRepository objects pointing at the same or different repos re-download N full indexes per interval, forever, even when nothing changed. In multi-tenant setups where each tenant namespace declares its own HelmRepository (cross-namespace refs disabled), N grows with the tenant count.
Measurements
Bench: k3s + source-controller v1.9.3, defaults; one HTTP helm repo with a 6.0 MB index; N HelmRepository objects with interval: 1m; server-side byte/request counters; idle steady state (index unchanged), 5-minute windows.
| N objects | index GETs / 5 min | bytes / 5 min | projected / day |
|---|---|---|---|
| 1 | 5 | 31.0 MB | 1,440 GETs / 8.9 GB |
| 10 | 50 | 309.7 MB | 14,400 GETs / 89 GB |
| 50 | 249 | 1.54 GB | ~72,000 GETs / ~444 GB |
Every one of those bytes is thrown away: the digest comparison concludes "unchanged" after each download.
Proposal
Remember the ETag / Last-Modified response headers per object (an in-memory map keyed by object UID is sufficient — a controller restart just pays one full fetch), and send If-None-Match / If-Modified-Since on the next reconcile. On 304 Not Modified, short-circuit to the existing no-op path without touching the body. When the server sends no validators, behaviour is unchanged.
GitHub Pages, S3/CloudFront, Cloudflare, nginx/static hosting and Harbor all emit validators for static index files, so the common cases are covered.
This mirrors what the controller already does for the other source kinds — GitRepository checks advertised refs before cloning, OCIRepository resolves the manifest digest via HEAD before pulling — HelmRepository/HTTP is the only kind that must download the full payload to discover nothing changed.
Happy to send the PR.
- Lenguaje dominante
- Go
- Estrellas
- 283
- Forks
- 258
- Merge medio
- 1 d 17 h
- PR fusionados (30 d)
- 15
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de fluxcd/source-controller
-
Improve documentation on debugging the controller locallyQuizá libre de nuevo @Bryandero98 la tomó hace 26 días y no hay ningún pull request abierto. Abiertoarea/docs good first issue help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
fluxcd/source-controller#666 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
area/oci enhancement
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
fluxcd/source-controller#2180 ·
Los mantenedores suelen responder en 1 día
-
`OCIRepository`/cosign verification: support TSA-only trusted roots (no transparency log) for private Sigstore instances like GitHub Artifact AttestationsPosiblemente ocupada @stealthybox la tomó hace 140 días. Abiertoarea/oci area/security enhancement
Dificultad 4/5 3-5 días Aptitud para principiantes 68/100
fluxcd/source-controller#2167 · 4 comentarios · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
fluxcd/source-controller#2150 ·
Los mantenedores suelen responder en 1 día
-
GitRepository `.spec.ref.commit` + `.spec.ref.branch` does not shallow clone, contrary to the docsAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 42/100
fluxcd/source-controller#2146 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
Todos los issues de fluxcd/source-controller
Issues similares
-
unbounded value for n in `/v1/logs` can panic/OOMPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertosmall item
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
canonical/pebble#1127 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
[schema-coverage] elasticstack_elasticsearch_synonym_set (data source)Posiblemente ocupada @github-actions la tomó hoy. Abiertoacceptance-tests phase-coding schema-coverage testing triaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 81/100
elastic/terraform-provider-elasticstack#5211 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 89/100
open-policy-agent/opa#9366 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
defect
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
nats-io/nats-server#8752 ·
Los mantenedores suelen responder en 1 día
-
enhancement needs-acceptance wg/router-models-inference-runtime
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
vllm-project/semantic-router#5015 · 1 comentario ·
Los mantenedores suelen responder en 1 día