Closed andybouts closed 2 years ago
The /mnt location is dynamic and that's controlled by the Ubuntu images used for the Jump/NFS VM's. There is confusion on the /mnt points of the pods vs mount points of the vm's. I can talk to this in a conversation if needed. The mount point on the Jump box can change with this variable jump_rwx_filestore_path
but again, it cannot be /mnt. Also your statements about the mount points inside the pods is not correct. So again a conversation needs to take place.
Hey @thpang , thanks for chatting offline. It seems there's 2 options to consider -- I think we can close this for now unless anyone on the testing team wants to validate this. I'm not sure if I will have time to validate it in the next few weeks.
1) doing a modification of the template file (but any git pull / git fetch from master would over-ride this mod)
https://github.com/sassoftware/viya4-deployment/blob/main/roles/vdm/templates/transformers/cas-add-nfs-mount.yaml
2) a symlink on the jump server to link /mnt/access-clients
to the directory on the nfs at /viya-share/..
I am working on deploying SAS Access to Snowflake. To do this, the drivers (OBBC, etc) need to be installed on a bastion host and mounted inside the pods.
The problem is that we have inconsistent mounts:
/viya-share
and the IAC doc indicates it cannot be reconfigured to mount to a root of/mnt
/mnt
/viya-share
is mounted with a root of/mnt
That said, in order to install the drivers and test them from the jump host and ensure that they run the exact same way inside the pods, the mount paths for both need to match.
If we could have the IAC mount the NFS at
/mnt
instead, that would fix the problem since everything would be consistently mounted.Alternatively, if we could mount the NFS inside the Viya pods with a root of
/viya-share
, that could also work.Any other ideas or am I missing anything?