BookmarkSubscribeRSS Feed

Configuring SAS Viya for Python Integration

Started ‎12-02-2022 by
Modified ‎11-10-2023 by
Views 18,323

One of the core tenets of SAS Viya is providing better integration with open-source languages such as Python. Users should have the flexibility to decide which language they want to use for a given task, allowing for a mix of Python code and traditional SAS code which opens a world of possibilities.  Administrators have a bit of configuration to do to make Python available to SAS Viya processes, all of which is documented in several README files found in the deployment assets.  I recently went through this process and wanted to share the steps I followed to fully integrate Python into a SAS Viya deployment I use for research to provide a consolidated picture of the process.

 

To configure Python integration with SAS Viya I followed the instructions in $deploy/sas-bases/examples/open-source-config/README.md and added steps 6 and 7 for completeness:

 

  1. Configure pre-requisite persistent storage for ASTORES required by MAS
  2. Install Python and additional packages
  3. Make Python visible to SAS Viya
  4. Configure SAS Viya to connect to Python
  5. Enable lockdown access methods for Python
  6. Enable watchdog which enforces lockdown settings for Python processing
  7. Configure CAS for external languages.

 

My initial goal was to make Python available to the compute sessions of SAS Studio users.  As I worked through these steps, I found that the process would also enable Python integration for CAS and the SAS Micro Analytic Service (MAS) at the same time. Including step 7 allowed me to fully integrate Python with SAS Viya.

 

Because there are several SAS Viya integration points with Python (e.g., using PROC PYTHON, SAS Visual Forecasting's TSMODEL procedure, the FCMP procedure, etc.), not every step above is required for each integration method.  For example, steps 5 and 6 that deal with LOCKDOWN have no impact on using Python with SAS Visual Forecasting or MAS.  While it is possible to configure only specific integration points, it makes sense to me, as an administrator, to configure all of the integration points at once so my users are free to choose the most appropriate option for their work without the need for me to configure additional options later.

 

As we step through the process, I will try to point out the key modifications that need to be made.

 

Note: Throughout this post I will use $deploy as a reference to a SAS Viya deployment directory.  On my research system $deploy refers to ~/project/deploy/gelcorp.  The $deploy directory contains the base kustomization.yaml file and the sas-bases and site-config directories of your SAS Viya deployment.  

 

1. Configure persistent storage for ASTORES

 

MAS requires an ASTORES persistent volume claim (PVC), so this first step simply defines the storage requirements for the PVC.  The instructions for this are in $deploy/sas-bases/examples/sas-microanalytic-score/astores/README.md. Copy the files from $deploy/sas-bases/examples/sas-microanalytic-score/astores to $deploy/site-config/sas-microanalytic-score/astores:

 

export deploy=~/project/deploy/gelcorp
mkdir -p $deploy/site-config/sas-microanalytic-score/astores 
cp $deploy/sas-bases/examples/sas-microanalytic-score/astores/* "$_"
chmod 755 $deploy/site-config/sas-microanalytic-score/astores/*.yaml

 

Edit $deploy/site-config/sas-microanalytic-score/astores/resources.yaml and provide values for storage and storageClassName.  I am using the NFS storage class and I am claiming 3Gi capacity.

xxx

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sas-microanalytic-score-astores 
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 3Gi #change this to desired capacity
  storageClassName: nfs-client #change this the desired storage class

 

Add site-config/sas-microanalytic-score/astores/resources.yaml to the resources field of your base kustomization.yaml file.

 

resources: 
  ... 
  - site-config/sas-microanalytic-score/astores/resources.yaml
  ...

 

Add sas-bases/overlays/sas-microanalytic-score/astores/astores-transformer.yaml to the transformers field of your base kustomization.yaml file.

 

transformers: 
  ... 
  - sas-bases/overlays/sas-microanalytic-score/astores/astores-transformer.yaml
  ...

2. Install Python

 

As an administrator you may already have Python installed or you may choose to handle the installation of Python on your own.  If you care to use it, SAS provides the SAS Configurator for Open Source utility, which automates the download and installation of Python from source by creating and executing the sas-pyconfig job.

 

I chose to use the SAS Configurator for Open Source to install Python so I followed the instructions in $deploy/sas-bases/examples/sas-pyconfig/README.md.

 

You can read more details about installing Python in Using the SAS Configurator for Open Source to Build Python and R.  

 

3. Make Python Visible to SAS Viya

 

Now that Python is installed on persistent storage, you need to make that storage available to the MAS, CAS, and launcher-based pods so they can access Python.

 

Instructions for this step are documented in $deploy/sas-bases/examples/sas-open-source-config/python/README.md.

 

The first step is to copy the example manifest files from $deploy/sas-bases/examples/sas-open-source-config/python to your $deploy/site-config/sas-open-source-config/python directory so you can configure them for your deployment.

 

mkdir -p $deploy/site-config/sas-open-source-config/python
cp $deploy/sas-bases/examples/sas-open-source-config/python/* "$_"
chmod 755 $deploy/site-config/sas-open-source-config/python/*.yaml

 

Now you can edit $deploy/site-config/sas-open-source/python/python-transformer.yaml which will define the mountPath of the Python persistent storage.  This one file defines the Python mount for MAS, CAS, and the launcher pods (e.g., compute).

 

Within python-transformer.yaml, identify the persistent volume that contains your Python install.  Since I used the SAS Configurator for Open Source to build Python, I will need to change all four occurrences of this volume definition.

 

# Add python volume
- op: add
  path: /template/spec/volumes/-
  value: { name: python-volume, {{VOLUME-ATTRIBUTES}}}

to identify the sas-pyconfig persistent volume claim (PVC) that the SAS Configurator for Open Source used when it built Python.  The sas-pyconfig PVC is created when you deploy SAS Viya.

 

If you manage your own Python build on other persistent storage you will need to change the template above to point to NFS or other storage class that you use store Python.  There are examples of alternative configurations in the $deploy/sas-bases/examples/sas-open-source-config/python/README.md.

 

# Add python volume
- op: add
  path: /template/spec/volumes/-
  value:
    name: python-volume
    persistentVolumeClaim:
      claimName: sas-pyconfig

With the python-volume identified, you now need to define the mountPath for the Python volume, which is the path name by which pods will access Python.  If you manage your own Python storage you can set this to any value as long as you remember it for later.

 

As covered in Using the SAS Configurator for Open Source to Build Python and R, the sas-pyconfig job creates symbolic links that enable me to dynamically refer to the most current build using profile names.  As of this writing, the symbolic links require a mount path of /opt/sas/viya/home/sas-pyconfig so that is what I configured here instead of the default mountPath value of /python.  I modified all occurrences of the mountPath definition in my file to look like this, including one easy to miss mountPath reference in the MAS section that is slightly different from the other three.

 

# Add mount path for python
- op: add
  path: /spec/controllerTemplate/spec/containers/0/volumeMounts/-
  value:
    name: python-volume
    mountPath: /opt/sas/viya/home/sas-pyconfig
    readOnly: true

 

What this means is that the SAS Viya MAS, CAS, and launcher-based pods can invoke my default profile's build of Python with this command:

 

/opt/sas/viya/home/sas-pyconfig/default_py/bin/python3

The last change we need to make in python-transformer.yaml is down toward the bottom where we need to allow the Open Code node of SAS Visual Data Mining and Machine Learning to invoke Python.  This value needs to identify the fully qualified path to the Python executable.

 

The value I used includes the Python mount path I configured earlier plus default_py, which is the symbolic link for the default Python profile, followed by bin/python3 which is the Python executable.

 

---
apiVersion: builtin
kind: PatchTransformer
metadata:
  name: add-python-sas-java-policy-allow-list
patch: |-
  - op: add
      path: /data/SAS_JAVA_POLICY_ALLOW_DM_PYPATH
      value: /opt/sas/viya/home/sas-pyconfig/default_py/bin/python3

 

One of the advantages of using the SAS Configurator for Open Source is that it will always automatically keep the symbolic links for each profile updated to refer to the latest build.  This means that we can configure this value one time and not need to change it for subsequent build changes.

 

Save the changes and then add $deploy/site-config/sas-open-source-config/python/python-transformer.yaml to the transformers field of your base kustomization.yaml before the sas-bases/overlays/required/transformers.yaml.

 

transformers:
  ...
  - site-config/sas-open-source-config/python/python-transformer.yaml
  - sas-bases/overlays/required/transformers.yaml
  ...


4.Configure SAS Viya to connect to Python

 

With Python mounted to our SAS Viya pods, the next step is to provide MAS and compute pods with the fully qualified commands to Python and to additional configuration elements.

 

Instructions for this step are located in $deploy/sas-bases/examples/sas-open-source-config/python/README.md.

 

To do this, you need to edit $deploy/site-config/sas-open-source-config/python/kustomization.yaml which is one of the files you copied over in step #3. his file creates environment variables that are made available in the SAS Viya pods. These new environment variables tell SAS Viya where to look for the Python executables and associated libraries.

 

Referencing the mount path defined in step #3, I configured these four variables, leaving the others at the defaults.

 

  • MAS_PYPATH which is used by SAS Micro Analytic Service
  • PROC_PYPATH which is used by PROC PYTHON in compute servers
  • DM_PYPATH which is used by the Open Source Code node in SAS Visual Data Mining and Machine Learning
  • SAS_EXTLANG_SETTINGS which controls access to Python from CAS (more on this later)
  • SAS_EXT_LLP_PYTHON which is used when the base distribution or packages for open-source software require additional run-time libraries that are not part of the shipped container image, similar to the LD_LIBRARY_PATH concept.
configMapGenerator:
- name: sas-open-source-config-python
  literals:
  - MAS_PYPATH=/opt/sas/viya/home/sas-pyconfig/default_py/bin/python3
  - MAS_M2PATH=/opt/sas/viya/home/SASFoundation/misc/embscoreeng/mas2py.py
  - PROC_PYPATH=/opt/sas/viya/home/sas-pyconfig/default_py/bin/python3
  - PROC_M2PATH=/opt/sas/viya/home/SASFoundation/misc/tk
  - DM_PYPATH=/opt/sas/viya/home/sas-pyconfig/default_py/bin/python3
  - SAS_EXTLANG_SETTINGS=/opt/sas/viya/home/sas-pyconfig/extlang.xml
  - SAS_EXT_LLP_PYTHON=/opt/sas/viya/home/sas-pyconfig/default_py/lib/python3.8/lib-dynload
- name: sas-open-source-config-python-mas
  literals:
  - MAS_PYPORT= 31100

Save the changes and add a reference to this file in the resources field of the base kustomization.yaml file.

 

resources: 
  ... 
  - site-config/sas-open-source-config/python 
  ...


5. Enable lockdown access methods for Python

 

For security reasons, SAS Viya compute servers are configured in LOCKDOWN mode which prohibits users from invoking external processes. The next step enables communication between Python and SAS Viya compute servers in LOCKDOWN.

 

Details for this step are in $deploy/sas-bases/examples/sas-programming-environment/lockdown/README.md.

 

Copy $deploy/sas-bases/examples/sas-programming-environment/lockdown/enable-lockdown-access-methods.yaml to $deploy/site-config/sas-programming-environment/lockdown/enable-lockdown-access-methods.yaml.

 

mkdir -p $deploy/site-config/sas-programming-environment/lockdown
cp $deploy/sas-bases/examples/sas-programming-environment/lockdown/* "$_" 
chmod 755 $deploy/site-config/sas-programming-environment/lockdown/*.yaml

Edit $deploy/site-config/sas-programming-environment/lockdown/enable-lockdown-access-methods.yaml.  You will need to enable python and python_embed methods for most, if not all, Python integration points; the socket method is also required to enable PROC Python and the Python Code Editor.

 

...
patch : |-
- op: add
  path: /data/VIYA_LOCKDOWN_USER_METHODS
  value: "python python_embed socket"
...

Save the changes and add a reference to this file in the resources field of the base kustomization.yaml file.

 

transformers: 
  ... 
  - site-config/sas-programming-environment/lockdown/enable-lockdown-access-methods.yaml 
  ...


6. Enable watchdog to enforce lockdown settings for Python processing

 

While compute server sessions are locked down by default, Python processes are not.  Fortunately, the SAS Compute Server provides the ability to execute SAS Watchdog, which monitors the spawned Python processes to ensure that they comply with the terms of LOCKDOWN system options.

 

SAS Watchdog emulates the restrictions imposed by LOCKDOWN by restricting access only to files that exist in folders that are allowed by LOCKDOWN.

 

This step is not required but I expect most SAS Viya administrators will want to enable this feature.  Information on the watchdog process is found in $deploy/sas-bases/overlays/sas-programming-environment/watchdog/README.md.

 

To enable watchdog, simply add a reference to $deploy/sas-bases/overlays/sas-programming-environment/watchdog to the transformers field of your base kustomization.yaml before the required transformers.yaml.

 

transformers: 
  ... 
  - sas-bases/overlays/sas-programming-environment/watchdog 
  - sas-bases/overlays/required/transformers.yaml
  ...


7. Configure CAS for external languages

 

There are a few additional steps to configure CAS for external language integration.  Normally, the CAS process runs as the 'sas' user which has permissions and privileges that we do not want external languages to have access to.  Therefore, we need to configure CAS to launch sessions using the identity of the user for better access control.

 

Enable host identity sessions

 

The first step is to configure CAS for host access which enables CAS to do host identity session launching. Copy $deploy/sas-bases/examples/cas/configure/cas-enable-host.yaml to $deploy/site-config and reference it in your base kustomization.yaml file's transformers field before the required transformers.yaml.

 

transformers: 
  ... 
  - site-config/cas-enable-host.yaml 
  - sas-bases/overlays/required/transformers.yaml
  ...


Configure users who need host identity sessions

 

For any CAS user needing to run Python, one of the following is required for user authentication:

 

  • If only selected users require access to Python, those users must be a member of the CASHostAccountRequired group. For information, see The CASHostAccountRequired Custom Group in SAS Viya: Identity Management. Be aware that when you create the CASHostAccountRequired custom group, the ID (CASHostAccountRequired) is case-sensitive.
  • Alternatively, the CASALLHOSTACCOUNTS environment variable can be set which enables host identity sessions for all users. For information, see env.CASALLHOSTACCOUNTS in SAS Viya: SAS Cloud Analytic Services.

 

I used SAS Environment Manager to create the CASHostAccountRequired custom group and added three users to it: geladm (my administrator), Delilah, and Henrik.

 

Configure CAS access for External Languages

 

This step is needed if you intend to use Python with SAS Visual Forecasting's TSMODEL procedure and/or its timedata.RunTimecode action, or FCMP.

 

The TSMODEL procedure of SAS Visual Forecasting includes an External Language (EXTLANG) package that enables users to incorporate code from external languages such as Python and R.  Because the functionality of the EXTLANG package might conflict with security policies, the EXTLANG package includes mechanisms that enable CAS server administrators to control users’ access to installed external-language interpreters and usable storage areas.

 

Access to external languages is managed by way of an XML file. Back in step #4 we configured an environment variable SAS_EXTLANG_SETTINGS with a value of/opt/sas/viya/home/sas-pyconfig/extlang.xml.  This identifies extlang.xml as the file containing access control information for CAS to use with the EXTLANG package of TSMODEL.

 

The file has to be accessible to CAS, and because it relates to Python, I chose to add the XML file to the sas-pyconfig persistent volume.

 

My extlang.xml file allows my three test Python users access to Python and R; allows geladm to set environment variables and specify a different Python or R interpreter, and allows Henrik and Delilah to run Python and R code but not to change interpreters or set new environment variables.  All other users will be blocked from accessing external languages from CAS.

 

sm_1_py_extlang.png

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

 

For more information on this please see SAS Help Center: External Languages Access Control Configuration.

 

Configure CAS for external access (optional)

 

If your users are going to be accessing CAS from outside your Kubernetes cluster, you will need to configure CAS to accept external connections.  Because there are nuances to this step,

 

I suggest you read SAS Viya - Access CAS from Outside the Viya Deployment by my colleague Gilles Chrzaszcz that describes this step.

 

 

This step is not needed for my research deployment but is likely to be needed in situations where users want to access SAS Viya from their own machines or from other applications.

 

Apply the configuration changes

 

With the configuration complete, we need to rebuild the SAS deployment and apply the changes to the cluster.  How you do this is dependent upon the deployment method used with your SAS Viya deployment.  I use the SAS Deployment Operator which means that I rebuild the sasdeployment custom resource definition and then apply it to my cluster. If you use the manual deployment method then you will need to use kustomize to rebuild your site.yaml manifest and then apply that to your cluster.  

 

See Modify Existing Customizations in a Deployment for guidance on this task.

 

If you deployed using the viya4-deployment GitHub project, you should consult the project documentation for guidance.

 

Validate Python Access

 

At last!  It is time to make sure that everything is set up correctly.

 

Let's use a simple program in SAS Studio to make sure compute servers can run Python code.  Notice that the log verifies that a Python process was initialized and also lists the version of the Python interpreter.

 

sm_2_py_hello.png

 

We can also test SAS Studio's Python editor functionality with a simple Python program.

 

sm_3_py_pgm-1024x672.png

 

 Next, let's see if CAS can access Python.  I tested with a program that uses PROC TSMODEL to process data in CAS using Python code.  If you need example TSMODEL code to test with you can find a good example in SAS Help Center: Calculate Moving Average of the Airline Series.  Running this test as one of the three named users in the EXTLANG XML file above (geladm, Henrik, or Delilah) should show results.  Running as any other user will show that the user is not authorized to use the EXTLANG package.

 

sm_4_py_tsmodel-1024x585.png

 

Finally, let's make sure MAS can score Python models.  Rather than make a long post even longer, I am going to spare you the details of publishing a Python model to MAS for scoring.  Instead, I suggest you do as I did and follow the steps my colleague Hans Edert published in Running Python models in SAS using Kubernetes volumes and Azure Files storage.  Using Hans's instructions, I created the Python model in SAS Model Studio and ran the generated MAS validation test code.  A successful status indicates that the MAS configuration is functional.

 

sm_5_py_mas-1024x248.png

 

Summary

 

I know the steps to integrate Python with SAS Viya look like a lot of work, but it really does not take long to implement the changes.  Information for all of the steps above is spread across several README.md files in your deployment assets.  I hope, however, that having the information from those individual files outlined in this one post will make it easier for you to integrate Python with your SAS Viya deployment.

 

For more information...

 

Find more articles from SAS Global Enablement and Learning here.

Comments

Hi Great article. 
Perhaps you should clarify that this is for Viya 4 ?

As I think it is because you mention PVC and more 🙂
Lars

Thanks, Lars. Yes, I suppose I should have been more explicit about the context so thanks for the good suggestion.  

Hi Scott,

 

Thanks for the useful article!

I am wondering about this section "Configure CAS for external languages" - where in CAS do I use an external language? Can you provide a use-case?

 

Eyal

Hi Eyal, thanks for reading.

As far as I know, the only use cases for CAS to interact with external languages are those mentioned in the article (PROC TSMODEL, the timedata.RunTimecode action, and FCMP).  

As mentioned in the FCMP doc, Python functions can be used in FCMP and then I suppose the FCMP function could be used in DS2 code.  I have not tried that but I believe that's plausible with what I know of the "plumbing."

In any case, there is not currently a way to use arbitrary Python/R code with CAS beyond these avenues.  Hoping that someone will correct me if this is not right.

Hi Scott 

Thanks for sharing,

This is really helpful since related documents are separeted, and you bring them all together.

 

Quick question

how to [ add the XML file to the sas-pyconfig persistent volume]?

I have tried to use `kubectl cp` command to copy file from local to sas-cas-server-default-controller pod, but failed.

 

kubectl cp site-config/extlang.xml sas-cas-server-default-controller:/opt/sas/viya/home/sas-pyconfig/extlang.xml
Defaulted container "sas-cas-server" out of: sas-cas-server, sas-backup-agent, sas-consul-agent, sas-certframe (init), sas-config-init (init)
tar: extlang.xml: Cannot open: Read-only file system
tar: Exiting with failure status due to previous errors
command terminated with exit code 2

Hi Li,

If you want to do what the blog suggests, you need to determine where the persistent volume is for the sas-pyconfig PVC.  In our lab machines, we use the NFS storage class for persistent storage so code like this gives us the actual path to the volume:

volume=$(kubectl describe pvc sas-pyconfig | grep Volume: | awk '{print $NF}')
pvPath=$(kubectl describe pv ${volume} | grep Path: | awk '{print $NF}')
echo pvPath is ${pvPath}

You will need sudo or a privileged account to copy extlang.xml to $pvPath but once you have it there, the change-configuration.xml should take care of mounting the path to your CAS pods so there should be no need for you to have to copy the file yourself.

Hope that helps. 

Version history
Last update:
‎11-10-2023 10:47 AM
Updated by:
Contributors

SAS Innovate 2025: Save the Date

 SAS Innovate 2025 is scheduled for May 6-9 in Orlando, FL. Sign up to be first to learn about the agenda and registration!

Save the date!

Free course: Data Literacy Essentials

Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning  and boost your career prospects.

Get Started

Article Tags