feat(connect): add tpl evaluation for extraVolumes and extraVolumeMounts#1719
Merged
josephwoodward merged 2 commits intoredpanda-data:mainfrom Feb 19, 2026
Merged
feat(connect): add tpl evaluation for extraVolumes and extraVolumeMounts#1719josephwoodward merged 2 commits intoredpanda-data:mainfrom
josephwoodward merged 2 commits intoredpanda-data:mainfrom
Conversation
pallotron
requested review from
RafalKorepta,
andrewstucki and
chrisseto
as code owners
|
|
Contributor
Author
|
@RafalKorepta @chrisseto @andrewstucki hey folks, it's been 8 days since I put this up. Is it possible to get it merged? I need this in the place I work and currently have to fork this... |
Contributor
RafalKorepta
left a comment
RafalKorepta
left a comment
There was a problem hiding this comment.
From my side it looks good. It would be good to add test.
I asked connect team to review and approve.
When using the connect chart as a subchart dependency, users often need
to reference ConfigMaps created by the parent chart. These ConfigMaps
typically use the parent chart's fullname helper to ensure proper
namespacing with the release name.
Currently, extraVolumes and extraVolumeMounts use toYaml directly,
which renders values as literal strings. This forces users to hardcode
ConfigMap names, creating a mismatch when the parent chart uses dynamic
naming (e.g., {{ include "myapp.fullname" . }}-config).
This change wraps toYaml with tpl() to evaluate any Helm template
expressions in the values before rendering. This is a common pattern
used in other Helm charts for user-provided values that may contain
template expressions.
Example use case - parent chart values.yaml:
```
connect:
extraVolumes:
- name: my-config
configMap:
name: '{{ include "myapp.fullname" . }}-config'
```
The tpl function safely handles values without template expressions,
so this change is backward compatible.
Contributor
Author
thanks @RafalKorepta let me add something... |
pallotron
force-pushed
the
tpl_evaluation
branch
from
329fb17 to
d3c357a
Compare
Contributor
Author
|
I added tests: |
Contributor
Author
|
Contributor
Author
|
@chrisseto @andrewstucki ping! can you review this? |
josephwoodward
approved these changes
Feb 19, 2026
Contributor
|
Thank you for your contribution @pallotron, sorry it took so long for us to get around to reviewing/merging this. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
When using the connect chart as a subchart dependency, users often need to reference ConfigMaps created by the parent chart. These ConfigMaps typically use the parent chart's fullname helper to ensure proper namespacing with the release name.
Currently, extraVolumes and extraVolumeMounts use toYaml directly, which renders values as literal strings. This forces users to hardcode ConfigMap names, creating a mismatch when the parent chart uses dynamic naming (e.g., {{ include "myapp.fullname" . }}-config).
This change wraps toYaml with tpl() to evaluate any Helm template expressions in the values before rendering. This is a common pattern used in other Helm charts for user-provided values that may contain template expressions.
Example use case - parent chart values.yaml:
The tpl function safely handles values without template expressions, so this change is backward compatible.