sassoftware/viya4-iac-azure

Integration with Python

zwyszomi opened this issue · 2 comments

Terraform Version Details

4.3.0

Terraform Variable File Details

No response

Steps to Reproduce

There is a problem when deployed Viya have to be integrated Python environment (via NFS - Python installed on NFS Srv. share)
By default NFS Srv VM is created on Ubuntu 20.04 but AKS nodes on Ubuntu 18.04
To install Python on NFS share the Python dist. have to be compiled from the source to be assure that entire Py env is placed on the shared folder only.
When such Python share in mounted on AKS node there is and error. Python compiled on Ubuntu 20.04 can't be executed on 18.04 (gcc library error)
Therefore additional VM has to be created (Ubuntu 18.04) only for Python environment.

Expected Behavior

The ideal solution will be when terraform.tfvars will contain the variable to specify Ubuntu version for NFS Server.
In modules/azurerm_vm there is a section which can be used for it but to specify the 18.04 it's a bit tricky
variable "os_offer" {
default = "UbuntuServer"
}
variable "os_sku" {
default = "18_04-lts-gen2"
}
variable "os_version" {
default = "latest"
}

I think such additional variables can save a lot of time during the further Viya deployment configuration

Actual Behavior

In SAS Viya documentation NFS Server is specified as a one of preferred approach to share Python distribution.
Unfortunately detailed customization is needed?

Additional Context

No response

References

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

What happens if the customer creates a cluster with CBLMariner as the OS type of the nodes? This is an option and if they bring their own how will this work? You have created an artificial dependency on the OS of your bastion box and the nodes in your kubernetes cluster which you may not have control over. The changes you made will help with the issue you've explained; however, it would be better to find a solution that does not depend on specificity of the nodes in a running cluster. This would also apply to our AWS/GCP/OSS solutions as well. We'll keep this one open so that we can discuss, but again, it's best not to rely on the cluster nodes themselves but on the kubernetes environment. Thx.

@zwyszomi any information based on my comments above? If not we'll be looking to close this one based on those comments.