Open tibbe opened 3 years ago
Does this feature request make sense?
If Rook just needs to create the loadbalancer service when the loadBalancerIP is set, I could see this being straight forward to implement. The question then becomes what else needs to be configured in ganesha as you mentioned to get it working end to end.
@tibbe Are you interested in implementing the feature? We are looking for more contributors to the nfs operator.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contributions.
running into this issue, after a power outage, my nfs nodeport or maybe it was a loadbalancer ip didn't come back up ... this is because it wasn't all done via gitops, i had to rig a solution and now i've got to figure out again how i did that, if it were defined in the helm chart then it'd be taken care of, so if this still hasn't been implemented i upvote it
Is this a bug report or feature request?
What should the feature do: Allow for the NFS service, generated implicitly by the NFS operator from the NFS configs described in Network Filesystem (NFS), to be configured as a load balancer with an IP set through
spec.loadBalancerIP
. As a consequence of allowing an external IP, the generated NFS-Ganesha config might also need to change to allow connections from outside the cluster.I believe the latter is needed as I tried adding a second (load balancer) service to expose the pod created by the Rook NFS operator, which resulted in hosts on the host network (e.g. 192.168.1.0/24) to be able to connect to the load balancer service while hosts (e.g. 172.19.27.38) outside that network couldn't. This is the config I used:
(This is the same as https://github.com/rook/rook/issues/7674 but for the regular, non-Ceph-specific, Rook NFS support.)
What is use case behind this feature:
Expose NFS outside the cluster through an IP.
Environment: