-
Notifications
You must be signed in to change notification settings - Fork 206
feature: (helm) support custom volumes and volumeMounts for epp #1945
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature: (helm) support custom volumes and volumeMounts for epp #1945
Conversation
|
Hi @delavet. Thanks for your PR. I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
✅ Deploy Preview for gateway-api-inference-extension ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
/retest |
Signed-off-by: Hang Yin <luying.yh@alibaba-inc.com>
8b55165 to
f782177
Compare
|
Sorry, it seems that there was an issue with golangci-lint in my branch. I have rebased main to resolve this problem. Please help re-review it.🫡 @nirrozenbaum |
|
|
||
| --- | ||
| {{- if .Values.inferenceExtension.sidecar.enabled }} | ||
| {{- if and .Values.inferenceExtension.sidecar.enabled .Values.inferenceExtension.sidecar.configMap }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is .Values.inferenceExtension.sidecar.configMap option?
I don't see it documented in the README.
additionally - maybe we can standardize the name (instead of configMap.name) and then then only relevant field would be some free form of configMapData?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I know, the ability to deploy a sidecar for EPP was initially introduced in #1821. The primary purpose was to deploy an Envoy as a sidecar for EPP to achieve standalone deployment. The main purpose of ConfigMap is to provide startup configuration for Envoy.
The reason I made changes here is to support the generalization of this capability, since some EPP Sidecars may not require the deployment of a corresponding ConfigMap.
However, a series of fields related to the sidecar that were added at the time were not well documented in the README. I have now updated and supplemented them.
additionally - maybe we can standardize the name (instead of configMap.name) and then then only relevant field would be some free form of configMapData?
I think this comment is very reasonable, so I have made adjustments according to your suggestion. PTAL.
Signed-off-by: Hang Yin <luying.yh@alibaba-inc.com>
|
/ok-to-test |
| {{- include "gateway-api-inference-extension.latencyPredictor.containers" . | nindent 6 }} | ||
| volumes: | ||
| {{- if .Values.inferenceExtension.volumes }} | ||
| {{- toYaml .Values.inferenceExtension.volumes | nindent 6 }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit/question:
why do we do here:
{{- toYaml .Values.inferenceExtension.volumes | nindent 6 }} (toYaml at the beginning)
and in the configmap:
{{- .Values.inferenceExtension.sidecar.configMapData | toYaml | nindent 2 }} (toYaml after pipelining)?
not a blocker, asking out of curiosity and trying to understand if there is a reason for being inconsistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree: there are indeed many inconsistencies in syntax within the current Helm chart. I believe this is due to different contributors having varying syntax habits when working with Helm templates. However, in order to maintain the granularity of the current PR, I do not intend to unify all syntax within this PR. I suggest we create a new issue to track this problem. I can create an issue later to gather everyone's thoughts on this matter.👀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds like a good fit for a new issue.
Thanks 👍
|
/lgtm /hold in case you want to fix inconsistency in the chart (see question about the |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: delavet, nirrozenbaum The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/unhold |
What type of PR is this?
/kind feature
What this PR does / why we need it:
please see #1944 for details
Which issue(s) this PR fixes:
Fixes #1944
Does this PR introduce a user-facing change?: