-
Notifications
You must be signed in to change notification settings - Fork 263
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
Add support for different volume types #1633
Comments
I think it's best to add support for extra volumes to our existing volume support for configmaps and secrets ( |
Sure I was looking for some existing volume support but it didnt come up in my search. |
/assign |
/reopen |
@vyasgun: Reopened this issue. In response to this:
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/test-infra repository. |
Reopening this issue as #1679 addresses only half of the requested feature. |
Feature request
Add support for different volume types. In Serving we have recently added two different volume types: Emptydir and PVCs.
Use case
It would be nice to extend the cli to support volumes. Users can then use the cli to add volumes as they would normally do with
a yaml file when deploying services.
UI Example
This could work similarly to the
--extra-containers
flag. At minimum users should be able to pass the configuration for volumesat pod level and at container level via json/yaml data.
If it is found useful defaults could be added. For example if emptydir is used a default volume mount could be done under a predefined dir eg. /cache along with a predefined
emptyDir.medium
eg. memory.Examples:
{emptydir, pvc}-volumes-config
refers to the pod voumes field. Regarding the container volume mounts these can be configured either with an extra parameter eg.--emptydir-volumemounts
for the user container and rely on --extra-containers flag for the rest of the mounts targeting other containers. This should be extended in the future to support init-containers too./cc @rhuss
The text was updated successfully, but these errors were encountered: