Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Helm chart defaults don't work: storage mounts, service names, storage class, migration schedule

Abierto
  • ¿Algo no está bien?
#2,695 0 comentarios 0 reacciones 0 asignados Ver en GitHub

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
55/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
helm, kubernetes
Área
devops, infrastructure

Línea de trabajo

Start by rendering the chart with helm template ex k8s/exceptionless and read k8s/exceptionless/templates/config.yaml, jobs.yaml, storage.yaml, and the Elasticsearch and Redis templates. Check the rendered service names, storage mounts and claim settings, and migration CronJob schedule against the defaults described in the issue. Done means a default install connects to bundled services, storage jobs can access their files, the claim can use the cluster’s default storage class, and migrations run only when triggered.

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

Descripción

bug

A default install of k8s/exceptionless (no connection strings set) does not work end to end. The chart's fallback Elasticsearch and Redis services don't match the connection strings it generates, the event-posts job can't read posted events from the default folder storage, the storage claim targets an Azure-only class, and the "manual only" migration CronJob is scheduled to run.

Rendered with helm template ex k8s/exceptionless at c6583c14b.

Checklist

  • event-posts (and other storage jobs) don't mount the storage volume. With storage.connectionString unset, the chart uses provider=folder;path=/app/storage (config.yaml L39) and mounts the claim only in the app, API and work-item pods. The event-posts deployment has no volume, so EventPostsJob looks for payloads in its own empty /app/storage and every posted event fails with "Unable to retrieve payload". The cleanup-data and download-geoip-database CronJobs also use IFileStorage and have no mount. (Reported earlier in #580, closed without a chart change.)
  • Default Elasticsearch connection string points at a service the chart doesn't create. config.yaml L33 defaults to server=http://elasticsearch:9200, but the fallback service is named <fullname>-elasticsearch (elasticsearch.yaml L92-L95). Rendered: server=http://elasticsearch:9200 vs service ex-elasticsearch.
  • Default Redis connection string points at a service the chart doesn't create. config.yaml L34-L35 generates <fullname>-redis-master, but the fallback service is <fullname>-redis (redis.yaml L36-L39). Rendered: ex-redis-master,abortConnect=false vs service ex-redis.
  • Storage claim is Azure-only and can't be satisfied as written. storage.yaml hardcodes storageClassName: managed-csi-premium, which only exists on AKS, so the claim stays Pending elsewhere. On AKS that class is Azure Disk, which doesn't support ReadWriteMany filesystem volumes, so the ReadWriteMany claim can't bind there either.
  • "Never" migration CronJob runs every Monday in February. jobs.yaml L420 uses schedule: "0 0 29 2 1" # never, only manually. When both day-of-month and day-of-week are restricted, cron runs when either matches, so this fires at midnight on Feb 29 and on every Monday in February.

Expected

helm install with default values produces a working instance: jobs connect to the bundled Elasticsearch and Redis, posted events are processed, the claim binds on a typical cluster, and the migration job only runs when triggered.

Suggested fix

  • Mount the storage claim in every job that uses file storage (event-posts, cleanup-data, download-geoip-database), ideally through a shared helper in _helpers.tpl.
  • Default the Elasticsearch connection string to server=http://{{ fullname }}-elasticsearch:9200 and the Redis one to {{ fullname }}-redis,abortConnect=false.
  • Add storage.storageClassName (empty by default, so the cluster default is used) and storage.accessModes/storage.size values. Document that a ReadWriteMany-capable class (NFS, Azure Files, EFS) or an object-storage connection string is needed when pods run on more than one node.
  • Mark the migration CronJob suspend: true (keeping a valid schedule) so it only runs via kubectl create job --from=cronjob/....
Lenguaje dominante
C#
Estrellas
2.5k
Forks
508
Merge medio
2 d 17 h
PR fusionados (30 d)
40

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

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 exceptionless/Exceptionless

Todos los issues de exceptionless/Exceptionless

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.