Hostnames should be allowed for PersistentVolume.spec.nfs.server to survive IP address changes.

[bberst]

Is this a bug report or feature request?

• Bug Report

Deviation from expected behavior:

Persistent volumes are created with the NFSServer service static IP address (nfsserversvc.Spec.ClusterIP) for the NFS server field (PersistentVolume.spec.nfs.server). This link did not survive a node upgrade as the NFSServer service was assigned a new IP address.

https://github.com/rook/rook/blob/master/pkg/operator/nfs/provisioner.go#L154-L160

Expected behavior:

Hostnames should be allowed for PersistentVolume.spec.nfs.server to survive IP address changes.

How to reproduce it (minimal and precise):

Dynamic Persistent Volume creation (from creating Persistent Volume Claim using StorageClass) caches the static IP address of the NFS server at the time of creation. When the node running the NFSServer service was upgraded, the NFSServer service IP address changed. PersistentVolume.spec.nfs.server is immutable which requires a new PV to be created.

Environment:

• Cloud provider:
  • GCP
• Rook version (use rook version inside of a Rook Pod):

# rook version
rook: v1.5.0-alpha.0.393.g1761874
go: go1.15.7

• Kubernetes version (use kubectl version):

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.1", GitCommit:"5e58841cce77d4bc13713ad2b91fa0d961e69192", GitTreeState:"clean", BuildDate:"2021-05-12T14:18:45Z", GoVersion:"go1.16.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19+", GitVersion:"v1.19.9-gke.1900", GitCommit:"008fd38bf3dc201bebdd4fe26edf9bf87478309a", GitTreeState:"clean", BuildDate:"2021-04-14T09:22:08Z", GoVersion:"go1.15.8b5", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes cluster type (e.g. Tectonic, GKE, OpenShift):
  • GKE

[travisn]

@bberst The clusterIP of a K8s service is expected to be immutable and we rely on this in several places in Rook. For example, if you try to modify the clusterIP of the service, K8s will reject the request. Do you have more details on how you found the clusterIP changed? There could have been some other issue during the node upgrade that affected the PV, but it just shouldn't be a changing clusterIP.

[github-actions]

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.

[bberst]

@travisn Our changed IP was self inflicted - a result of our recovery efforts (i.e., replacing the existing resources). We are still experiencing problems trying to use the volume after the nfs-server relocates to a different node.

Busybox shows a Stale file handle

/ # df -h
Filesystem                Size      Used Available Use% Mounted on
overlay                  94.3G     10.7G     83.6G  11% /
tmpfs                    64.0M         0     64.0M   0% /dev
tmpfs                    62.9G         0     62.9G   0% /sys/fs/cgroup
df: /mnt: Stale file handle