-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Conversation
Welcome @therc! |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Naming aside, this could be made more generic so that you don't need to run a million alias provisioners if you have more than one NFS tree to expose to your namespaces. Let's say you have three existing claims: data, code, docs. You want them to be available in any number of other namespaces, as allowed by RBAC. You run the nfs-client provisioner If others agree that the generic, multi-claim approach is better, I can change alias mode to use NFS_PATH as the directory inside the provisioner's container where we look up mounted claims. In the example above, it would be set to |
This might be a solution for kubernetes-retired#1210 and kubernetes-retired#1275 In combination with an existing NFS claim in namespace X, allow the administrator or the users to create new claims for the same NFS tree in namespaces A, B, C, etc. This change tries as much as possible NOT to disrupt existing setups. A few things still left: 1. Is "alias" the right term? Previous choices I tossed out: clone (easy to mix with real volume cloning), proxy (there's no middle-man NFS server), passthrough (too nebulous). 1. Is NFS_SERVER=--alias the best way to trigger this? 1. Should the auto-detection of the server host:path happen always, even when not in alias mode? 1. Should the parent's ReadOnly field be propagated to the newly provisioned PV? 1. Should this be made more generic so that one deployment can expose N different claims/trees to the other namespaces? See comment below for more details.
Ping? |
@therc - We are in the middle of migrating the NFS client code into a new home under https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner. The migration PR is up for review at the moment. kubernetes-sigs/nfs-subdir-external-provisioner#2 Sorry to have kept mum on this PR for a while, can I circle back with you once the above migration PR is merged and take your help to shift these changes into the new repo? |
Sounds good, @kmova... thank you! |
As @kmova mentioned, we are in the process of archiving this repo and continuing work in https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner. Please reopen a PR in the new repo once kubernetes-sigs/nfs-subdir-external-provisioner#2 has merged. Thanks for your patience! :) Going to close this PR in order to be able to archive this repo. |
This might be a solution for #1210 and #1275
In combination with an existing NFS claim in namespace X, allow the administrator or the users to create new claims for the same NFS tree in namespaces A, B, C, etc.
This change tries as much as possible NOT to disrupt existing setups.
A few things still left: