Feat/persistence logs subpath

[CaioMartins968]

Problem

persistence.worker and persistence.logs both support existingClaim, which lets you point either volume at a PVC that already exists instead of having the chart provision a new one. This is useful whenever you want two of the chart's volumes to live on the same underlying PVC instead of two separate ones — for example, on storage backends that bill or provision per-PVC with a large minimum size (e.g. Azure Files "Provisioned v2" shares have a 32Gi minimum regardless of the requested size), where provisioning a second PVC just for logs (which typically holds a few MB of data) doubles the storage cost for no real benefit.

The problem is that neither volume's mount supports subPath. Both sites-dir (worker) and logs are mounted at the root of whatever PVC they're bound to. So if you set persistence.logs.existingClaim to the same PVC already used by persistence.worker, both volumes end up writing into the exact same root directory — logs's content lands mixed in with the worker's sites-dir tree (common_site_config.json, apps.txt, per-site folders, etc.) instead of living in its own subdirectory. There's no way to point two volumes at one PVC without their contents colliding.

Change

Adds an optional subPath field to both persistence.worker and persistence.logs, wired into the corresponding volumeMounts entry wherever each volume is mounted (all deployment-*.yaml and job-*.yaml templates that reference sites-dir and/or logs — 18 files in total, one repeated one-line pattern per volume type). When set, it's passed straight through as subPath on the mount; when unset (the default), the field is omitted entirely and rendering is byte-for-byte identical to today.

This mirrors the pattern the valkey subchart (dataStorage.persistentVolumeClaimName + dataStorage.subPath) already uses for exactly this purpose, so it's consistent with prior art already vendored in this chart.

Example usage — worker and logs sharing one PVC, isolated by subpath:

```yaml
persistence:
worker:
existingClaim: my-app-erpnext
logs:
enabled: true
existingClaim: my-app-erpnext
subPath: logs-data
```

Backward compatibility

Fully additive and opt-in. subPath defaults to unset, and the template guards it with {{- if .Values.persistence.worker.subPath }} / {{- if .Values.persistence.logs.subPath }}, so existing values files render identically to before this change — confirmed with helm template diffs against the default values.

Testing

• helm template with and without subPath set, for both persistence.worker and persistence.logs — confirmed the mount only gains a subPath line when the value is set, otherwise output is unchanged.
• helm lint passes.
• Live cluster verification (Kubernetes, Azure Files RWX PVC): two pods mounting the same PVC at different paths with different subPath values only ever see their own file, never each other's — and a third pod mounting the PVC without subPath sees both subdirectories cleanly separated at the root, confirming no content mixing. Also verified that data written under a subPath survives deleting and recreating the pod, i.e. it's genuinely persisted on the PVC rather than behaving like emptyDir.

[CaioMartins968]

@revant hey! Opened this small PR adding subPath support to persistence.worker and persistence.logs — would appreciate a look whenever you have a moment.

Context: on storage backends that provision per-PVC with a large minimum size (e.g. Azure Files Provisioned v2, which has a 32Gi floor regardless of the requested size), pointing persistence.logs.existingClaim at the same PVC already used by the worker is the only way to avoid paying for a second share just for logs. The problem is neither volume's mount supports subPath, so both end up writing to the same PVC root and mixing content. This PR just exposes subPath on both, mirroring the pattern the valkey subchart already uses for dataStorage.subPath.

It's small and fully backward compatible — subPath is optional and only added to the mount when set, so existing values files render identically. Tested with helm template/helm lint, and also verified live on a cluster that two volumes sharing one PVC via different subPath values stay isolated and persist correctly across pod restarts.

Happy to adjust anything if you'd rather see it done differently.

[revant]

can you fix the conflicts and CI

[CaioMartins968]

can you fix the conflicts and CI

@revant fixed both — rebased on latest main (conflict was just the Chart.yaml version bump) and the CI failure was helm-docs-built flagging drift because I'd hand-edited the generated README.md instead of README.md.gotmpl; moved the doc into the template and regenerated it for real, verified locally with pre-commit run --all-files (all green now).

Looks like the new run is sitting on action_required though — could you approve it from the Actions tab when you get a chance?

[greptile-apps]

Confidence Score: 5/5

[High risk] Kubernetes deployment templates now support volume subPath configuration.

The PR appears safe to merge.

_{Reviews (5) · Last reviewed commit: "Fail subPath init container when any mkd..."}

[CaioMartins968]

Hi @revant, @disha-itpl! 👋

This PR is ready for another look whenever you have a moment. Since the last
round I've:

• rebased on the latest main (conflict was only the Chart.yaml version bump)
• fixed the CI failure (helm-docs drift)
• addressed the automated review feedback:
  • subPath values are now quoted, so numeric names like 2024 render as strings
  • the README example uses distinct subpaths on both volumes and warns that
    existing site data must be moved into the subdirectory before switching
  • a small init container creates/chowns the subPath dir before the main
    containers start. It only appears when a subPath is set, skips the chown if
    ownership is already right, never fails the pod on a rejected chown
    (root-squashed NFS), and can be turned off with
    persistence.subPathPermissions.enabled=false

Everything is still fully backward compatible: with no subPath set, the rendered
manifests are identical to before.

Could one of you approve the workflow run (it's waiting on action_required) and
take a look? Happy to adjust anything if you'd prefer it done differently.
Thanks a lot for your time! 🙏