Drop the automatic creation of a PVC.

.github/workflows/ci.yaml

@@ -121,4 +121,4 @@ jobs:
           node_image: kindest/node:${{ matrix.k8s }}
 
       - name: Run chart-testing (install)
-        run: ct install --config .github/ct.yaml --helm-extra-args '--timeout 900s' --helm-extra-set-args '--set-json=persistence.accessModes=["ReadWriteOnce"]'
+        run: ct install --config .github/ct.yaml --helm-extra-args '--timeout 900s'

zammad/README.md

@@ -155,16 +155,24 @@ redis:
 
 ### From Chart Version 10.x to 11.0.0
 
-- The `StatefulSet` was split up into separate `Deployments`.
-  - `replicas` can be set independently now for `zammad-nginx` and `zammad-railsserver`, allowing free scaling and HA setup for these.
+#### The Previous `StatefulSet` Was Split up into `Deployments`
+
+- `replicas` can be set independently now for `zammad-nginx` and `zammad-railsserver`, allowing free scaling and HA setup for these.
   - For `zammad-scheduler` and `zammad-websocket`, `replicas` is fixed to `1` as they may only run once in the cluster.
-- The `initContainers` moved to a new `zammad-init` `Job` now which will be run on every `helm upgrade`.
+- The `initContainers` moved to a new `zammad-init` `Job` now which will be run on every `helm upgrade`. This greatly reduces startup time.
 - The nginx `Service` was renamed from `zammad` to `zammad-nginx`.
-- Storage requirements changed: Zammad now requires a `ReadWriteMany` volume that is shared in the cluster.
-  - If you already had one via `persistence.existingClaim` before, it should just keep working.
-  - If you used the default `PersistentVolumeClaims` of the `StatefulSet`, you will need to migrate your data to the new `PersistentVolumeClaim`.
 - The previous `Values.sidecars` setting does not exist any more. Instead, you need to specify sidecars now on a per deployment basis, e.g. `Values.zammadConfig.scheduler.sidecars`.
 
+#### Storage Requirements Changed
+
+- Zammad no longer requires a volume for `var/`
+- If you use the default `DB` or the new `S3` storage back end for file storage, you don't need to do anything.
+- If you use the `File` storage back end instead, Zammad now requires a `ReadWriteMany` volume for `storage/` that is shared in the cluster.
+  - If you already had one via `persistence.existingClaim` before, you need to ensure it has `ReadWriteMany` access to be mountable across nodes.
+  - If you used the default `PersistentVolumeClaim` of the `StatefulSet`, you need to take manual action:
+    - You can either migrate to `S3` storage before upgrading to the new major version as described above in [Configuration](#how-to-migrate-from-file-to-s3-storage).
+    - Or you can provide an `existingClaim` with `ReadWriteMany` permission and migrate your existing data to it from the old `StatefulSet`.
+
 ### From Chart Version 9.x to 10.0.0
 
 - all containers uses `readOnlyRootFilesystem: true` again

zammad/templates/_helpers.tpl

@@ -178,10 +178,10 @@ volume mounts for the Zammad Rails stack
 {{- define "zammad.volumeMounts" -}}
 - name: {{ template "zammad.fullname" . }}-tmp
   mountPath: /opt/zammad/tmp
-- name: {{ template "zammad.fullname" . }}-var
+{{- if .Values.zammadConfig.storageVolume.enabled }}
+- name: {{ template "zammad.fullname" . }}-storage
   mountPath: /opt/zammad/storage
-- name: {{ template "zammad.fullname" . }}-var
-  mountPath: /opt/zammad/var
+{{- end -}}
 {{- end -}}
 
 {{/*
@@ -190,19 +190,15 @@ volumes for the Zammad Rails stack
 {{- define "zammad.volumes" -}}
 - name: {{ include "zammad.fullname" . }}-tmp
   {{- toYaml .Values.zammadConfig.tmpDirVolume | nindent 2 }}
-{{- if and .Values.persistence.enabled .Values.persistence.existingClaim }}
-- name: {{ template "zammad.fullname" . }}-var
-  persistentVolumeClaim:
-    claimName: {{ .Values.persistence.existingClaim | default (include "zammad.fullname" .) }}
-{{- else if not .Values.persistence.enabled }}
-- name: {{ template "zammad.fullname" . }}-var
-  emptyDir:
-    sizeLimit: {{ .Values.persistence.size | quote }}
-{{- else if and .Values.persistence.enabled (not .Values.persistence.existingClaim) }}
-- name: {{ template "zammad.fullname" . }}-var
+{{- if .Values.zammadConfig.storageVolume.enabled }}
+{{- if .Values.zammadConfig.storageVolume.existingClaim }}
+- name: {{ template "zammad.fullname" . }}-storage
   persistentVolumeClaim:
-    claimName: {{ template "zammad.fullname" . }}-var
-  {{- end }}
+    claimName: {{ .Values.zammadConfig.storageVolume.existingClaim | default (include "zammad.fullname" .) }}
+{{- else }}
+  {{ fail "Please provide an existing PersistentVolumeClaim with ReadWriteMany access if you enable .Values.zammadConfig.storageVolume." }}
+{{- end -}}
+{{- end -}}
 {{- end -}}
 
 {{/*

zammad/values.yaml

@@ -208,6 +208,17 @@ zammadConfig:
     # can be used to add additional containers / sidecars
     sidecars: []
 
+  storageVolume:
+    # Enable this for 'File' based storage in Zammad. You must provide an externally managed 'extistingClaim'
+    #   with 'ReadWriteMany' permisssion in this case.
+    enabled: false
+    ##
+    ## A manually managed Persistent Volume and Claim
+    ## If defined, PVC must be created manually before volume will be bound
+    ## The value is evaluated as a template, so, for example, the name can depend on .Release or .Chart
+    ##
+    # existingClaim:
+
   tmpDirVolume:
     emptyDir:
       sizeLimit: 100Mi
@@ -365,20 +376,6 @@ autoWizard:
 podAnnotations: {}
   # my-annotation: "value"
 
-# Configuration for persistence
-persistence:
-  enabled: true
-  ## A manually managed Persistent Volume and Claim
-  ## If defined, PVC must be created manually before volume will be bound
-  ## The value is evaluated as a template, so, for example, the name can depend on .Release or .Chart
-  ##
-  # existingClaim:
-  accessModes:
-    - ReadWriteMany
-  storageClass: ""
-  size: 5Gi
-  annotations: {}
-
 nodeSelector: {}
 tolerations: []
 affinity: {}