-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Support Volume Mount Options #168
Comments
@kubernetes/sig-storage-misc |
@rootfs are you a person, responsible for the feature? |
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 |
@gnufied done. |
We have a case to pass selinux context as |
@saad-ali and I talked this over today and we both agree that making sure that working with rootfs on this is one of his now highest priorities, now that he is no longer under the release czar role. |
Yeah it is a top priority for us too. I am working on a design document with @rootfs and will publish it today. I apologize for not sending the design proposal sooner - got caught up in other feature requests. |
The design proposal - https://github.com/kubernetes/community/pull/321/files |
cc @lpabon |
@spxtr can we keep this open? we need to walk this feature through - beta, GA, docs and whole thing. |
@spxtr was this closed on purpose? |
@gnufied any update on this feature? Docs and release notes are required (please, provide them to the features spreadsheet. |
Sorry, I simply synced my fork, and thanks to this |
Added release notes to spreadsheet. The documentation PR is - kubernetes/website#2743 |
This is beta for 1.6 not stable updated labels and spreadsheet. |
@gnufied are we planning to bring this to stable in 1.7 |
This is not going to go to GA in 1.7 (it went beta in 1.6). We will punt GA to 1.8. |
We are going to try and get this GA in 1.8. The corresponding feature request change for taking this feature to GA - kubernetes/community#771 |
@idvoretskyi I didn't create this issue, @rootfs did - but I do own it. I can't edit the original description unfortunately. The feature went beta in 1.6 and is going GA in 1.8. |
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) |
@matthewceroni, in 1.8 we plan to add mountOptions to |
Automatic merge from submit-queue (batch tested with PRs 50919, 51410, 50099, 51300, 50296) Take mount options to GA by adding PV.spec.mountOptions **What this PR does / why we need it**: Implements kubernetes/community#771 issue: kubernetes/enhancements#168 **Special notes for your reviewer**: TODO: - ~StorageClass mountOptions~ As described in proposal, this adds PV.spec.mountOptions + mountOptions parameter to every plugin that is both provisionable & supports mount options. (personally, even having done all the work already, i don't agree w/ the proposal that mountOptions should be SC parameter but... :)) **Release note**: ```release-note Add mount options field to PersistentVolume spec ```
Automatic merge from submit-queue Add storageClass.mountOptions and use it in all applicable plugins split off from #50919 and still dependent on it. cc @gnufied issue: kubernetes/enhancements#168 ```release-note Add mount options field to StorageClass. The options listed there are automatically added to PVs provisioned using the class. ```
Automatic merge from submit-queue Implement support for mount options in PVs **What this PR does / why we need it**: This PR implements support for mount options in PersistentVolume via `volume.beta.kubernetes.io/mount-options` annotation. **Which issue this PR fixes** Fixes kubernetes/enhancements#168 **Release note**: ``` Enable additional, custom mount options to be passed to PersistentVolume objects via volume.beta.kubernetes.io/mount-options annotation. ```
Automatic merge from submit-queue Add storageClass.mountOptions and use it in all applicable plugins split off from kubernetes/kubernetes#50919 and still dependent on it. cc @gnufied issue: kubernetes/enhancements#168 ```release-note Add mount options field to StorageClass. The options listed there are automatically added to PVs provisioned using the class. ```
This feature has been implemented as speced. Closing. /close |
Automatic merge from submit-queue Implement support for mount options in PVs **What this PR does / why we need it**: This PR implements support for mount options in PersistentVolume via `volume.beta.kubernetes.io/mount-options` annotation. **Which issue this PR fixes** Fixes kubernetes/enhancements#168 **Release note**: ``` Enable additional, custom mount options to be passed to PersistentVolume objects via volume.beta.kubernetes.io/mount-options annotation. ```
Automatic merge from submit-queue Add storageClass.mountOptions and use it in all applicable plugins split off from kubernetes/kubernetes#50919 and still dependent on it. cc @gnufied issue: kubernetes/enhancements#168 ```release-note Add mount options field to StorageClass. The options listed there are automatically added to PVs provisioned using the class. ```
Initial --from-env-file proposal
Description
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
version=3,protoc=tcp,nolock
. It is the convention used by mount command. Since this solution only supported a subset of filesystem options, it is not subject to mount option changes. Arguably, the mount options are only for expert user who understand what they do. The mount options API object defaults to none.Google: @saad-ali @jingxu97
RedHat: @childsb @jsafrane
The text was updated successfully, but these errors were encountered: