fix: (IAC-1091) Prevent Jump VM cloud-init from overwriting existing file permissions/ownership

[jarpat]

Changes:

When a new jump server vm is created, it sets file ownership and permissions for the mounted NFS location which allows Viya services to initialize successfully. Importantly, the file system settings should only be applied once and not repeatedly in the event that the jump vm is destroyed and recreated in the same cluster. This change checks if the ${jump_rwx_filestore_path}/pvs folder already exists and skips creating the folder and recursively setting ownerships and permissions if it does. If the jump vm is being created for the first time when the pvs folder is absent, creating the folder and setting permissions and ownership will occur an initial time and not thereafter.

Tests:

Executed the following workflow to verify that file permissions and ownership was not modified on Jump VM recreation

Steps:

• Created cluster using viya4-iac-gcp
• Verify infrastructure created successfully
  • Checked initial permissions and ownership of files of mounted files system on Jump VM
• Deploy Viya4 using DaC
• Verify Viya deployment is stabilized
  • Checked permissions and ownership of files mounted on the Jump VM that were created by the Viya deployment
• Stop Viya. Stop a SAS Viya Platform Deployment
• Verify all pods are terminated
• Replace jump server vm using terraform replace command (Alternative to destroy and create), verified that the existing jump vm is destroyed and a new one is created.
• Start Viya Start a SAS Viya Platform Deployment
• Check deployment/pods status verify all Viya pods, services and applications stabilize and are accessible.
  • Checked that permissions and ownership of files mounted on the Jump VM that were created by the Viya deployment were not changed upon the rerun of the cloud init script.

[thpang]

This is fine and I know we recently did this for one of the other providers, we now have to ensure that if this directory exists that we document that on its initial run the permissions need to be set to 777 and the owner/group needs to be modified as nobody:nogroup as we now cannot guarantee this. So doc will be needed here and in the other provider or providers we've updated with this code check.

[jarpat]

This is fine and I know we recently did this for one of the other providers, we now have to ensure that if this directory exists that we document that on its initial run the permissions need to be set to 777 and the owner/group needs to be modified as nobody:nogroup as we now cannot guarantee this. So doc will be needed here and in the other provider or providers we've updated with this code check.

Hey @thpang, on this line in the cloud-init https://github.com/sassoftware/viya4-iac-gcp/blob/IAC-1091/files/cloud-init/jump/cloud-config#L34 we document the new functionality. Would making this section a bit more verbose to describe the updated behavior more clearly be what you are looking for?