Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support Volume Mount Options #168
We currently support network filesystems: NFS, Glusterfs, Ceph FS, SMB (Azure file), Quobytes, and local filesystems such as ext[3|4] and XFS.
Mount time options that are operationally important and have no security implications should be suppported. Examples are NFS's TCP mode, versions, lock mode, caching mode; Glusterfs's caching mode; SMB's version, locking, id mapping; and more.
One solution is to walk through all the mount options and create API objects for each one of them in their volume source. This solution clearly states what are the supported options. But supporting all valid mount options makes us liable to compatibility issues when mount options changes between OS distributions/releases, or between OSes (Linux, BSD/OSX if they are to be supported in the future)
Second solution also adds an API objects in volume source. Instead of 1-1 mapping, the single API object is a string comma separated blob like
This should be assigned to me. I unfortunately don't have enough privilege to do that myself - https://docs.google.com/spreadsheets/d/1t4z5DYKjX2ZDlkTpCnp18icRAQqOE85C1T1r2gqJVck/edit#gid=0
The design proposal - https://github.com/kubernetes/community/pull/321/files
referenced this issue
May 18, 2017
I see this is support on the PV via an annotation, but what about when using dynamic provisioning?
I attempted to add the annotation to the volumeClaimTemplate but that did not see to work.
FYI: This results in an EBS volume (when rendered via helm)