Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#2,695 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
55/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
helm, kubernetes
領域
devops, infrastructure

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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/....
主要言語
C#
スター
2.5k
フォーク
508
平均マージ
2日 17時間
マージ済み PR（30日）
40

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

exceptionless/Exceptionless のほかの issue

exceptionless/Exceptionless の issue をすべて見る

似ている issue

C# の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。