Allow custom volumeClaimTemplates when logs.persistence.enabled is true #60118
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes : #59571
Problem
Custom volumeClaimTemplates for workers were ignored when workers.persistence.enabled: true and logs.persistence.enabled: true. The volumeClaimTemplates section was only rendered in the {{- else }} branch, which only runs when logs.persistence.enabled: false. As a result, custom templates were never created, causing pods to fail with volume mount errors.
Root Cause:
The template logic in worker-deployment.yaml had the volumeClaimTemplates section nested inside an {{- else }} block that only executed when logs.persistence.enabled: false. When logs.persistence.enabled: true, the code took the first branch (creating logs as a regular PVC) and skipped the {{- else }} block entirely, preventing custom volumeClaimTemplates from being rendered.
Solution
Separated the volumeClaimTemplates logic from the logs volume handling. The volumeClaimTemplates section is now created independently when:
workers.persistence.enabled: true (StatefulSet is used), AND
Either logs.persistence.enabled: false (logs needs to be a template) OR custom volumeClaimTemplates are provided
This ensures custom volumeClaimTemplates are always rendered when provided, regardless of the logs persistence setting.