Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#2,695 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
55/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
helm, kubernetes
Lĩnh vực
devops, infrastructure

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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/....
Ngôn ngữ chính
C#
Star
2.5k
Fork
508
Merge trung bình
2 ngày 17 giờ
Pull request đã merge (30 ngày)
40

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của exceptionless/Exceptionless

Tất cả issue của exceptionless/Exceptionless

Issue tương tự

Thêm issue về C#

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.